Oficina de Gestin de Proyectos

La oficina de gestin de proyectos (PMO por sus siglas en ingls OGP por sus siglas en espaol) es un departamento o grupo que define y mantiene estndares de procesos, generalmente relacionados a la gestin de proyectos, dentro de una organizacin. La PMO se esfuerza por estandardizar y economizar recursos mediante la repeticin de aspectos en la ejecucin de diferentes proyectos. La PMO es la fuente de la documentacin, direccin y mtrica en la prctica de la gestin y de la ejecucin de proyectos. Una PMO podra basar sus principios de gestin de proyectos en metodologas y estndares en la industria, tales como PMI, ISO 9000 y requisitos reguladores de algunos gobiernos como el Acta Sarbanes-Oxley en los Estados Unidos, han propulsado a las organizaciones a estandardizar sus procesos. Organizaciones alrededor del mundo estn definiendo, compartiendo y recogiendo buenas prcticas en la gestin de procesos y proyectos. Cada vez ms, se est asignando a las PMO la responsabilidad de ejercer una influencia total sobre ellas, y de lograr una evolucin de pensamiento que lleve hacia la continua mejora de la organizacin. Las PMO pueden operar en aspectos que van desde proporcionar las funciones de respaldo para la direccin de proyectos bajo la forma de formacin, software, polticas estandarizadas y procedimientos, hasta la direccin y responsabilidad directas en s mismas para lograr los objetivos del proyecto.

Responsabilidades basicas de una PMO:

1. Elaborar planes de capacitacin y entrenamiento a los Gerentes de Proyecto y sus equipos de trabajo. 2. Documentar los procesos de gestin de proyectos. 3. Coordinacin de los proyectos a su cargo. 4. Administracin de los recursos asignados y/o compartidos en los proyectos 5. Monitorear y controlar los proyectos con indicadores de costo, tiempo y calidad del proyecto 6. Estimar y programar en alto nivel las etapas de los proyectos y su interaccin con otros planes. 8. Evaluacin asistida del retorno de la inversin ROI 9. Asistencia en la elabotracin del plan del proyecto 10.Soporte administrativo y tecnologico en las herramientas de proyectos.

Por qu una PMO (Oficina de Proyectos)?

Los profesionales vinculados a proyectos trabajan bajo una gran presin para poder entregar un producto en el tiempo estipulado y dentro de los costos estimados. Al mismo tiempo, la alta direccin de la organizacin se pregunta cmo incrementar operaciones utilizando nuevas tecnologas para tener una mejor visibilidad en las ventas, integrar sistemas y tener informes en tiempo real. En respuesta a esta presin los directores de las organizaciones estn buscando la forma de mejorar el desempeo en la administracin de diferentes proyectos. Para lograr esto se debe encontrar la mejor manera de gestionar mltiples proyectos, mantenerlos a todos visibles y permitir tomar decisiones basadas en informacin verdadera y actual. La Oficina de Proyectos (Project Management Office) es una forma de solucionar esta problemtica, ya que permite: * Gestionar la cartera de proyectos de la compaa. * Gestionar los objetivos de negocios. * Proveer informacin para la toma de decisiones. * Estandarizar y realizar una mejora continua de los procesos de desarrollo de la compaa. * Gestionar las expectativas de los ejecutivos y clientes internos de los proyectos. * Coordinar actividades y procesos que atraviesan toda la organizacin.

PMO
La oficina de gestin de proyectos (PMO por sus siglas en ingls) en un departamento o grupo que define y mantiene estndares de procesos, generalmente relacionados a la gestin de proyectos, dentro de una organizacin. La PMO se esfuerza por estandardizar y economizar recursos mediante la repeticin de aspectos en la ejecucin de diferentes proyectos. La PMO es la fuente de la documentacin, direccin y mtrica en la prctica de la gestin y de la ejecucin de proyectos .

La gestin de proyectos
Es la disciplina de organizar y administrar recursos de manera tal que se pueda culminar todo el trabajo requerido en el proyecto dentro del alcance, el tiempo, y coste definidos. Un proyecto es un esfuerzo temporal, nico y progresivo, emprendido para crear un producto o un servicio tambin nico. Las caractersticas o atributos comunes a la mayora de los proyectos son: - Objetivo (poner los pies en la tierra; la naturaleza del proyecto debe ser real, sustentable) - Calendario de Actividades (debe tener un programa de actividades o plan de trabajo) - Complejo (no es nada sencillo y esta compuesto por mltiples elementos) - Demanda recursos (Requiere habilidades, conocimientos, capital y equipo de diversas reas de una organizacin o comunidad) - Estructura organizacional (tiene roles y responsabilidades, ej. gerente de proyecto, lder de proyecto, sponsor, clientes, etc) - Sistema de Control e Informacin (por lo menos un sistema manual o automatizado de registrar la documentacin e informacin relacionada al proyecto) Segn PMI: - Temporal (tiene un principio y un fin; algn da debe terminar y alcanzar sus objetivos o simplemente abandonarse) nico (no significa que sea un milagro o nico en su especie sino que ha sido emprendido por un nico propsito, y porque solo su proyecto usar ese nico recurso, tiempo, espacio y dems recursos para ese nico momento) - Elaboracin Progresiva (los procesos y ciclos de vida del proyecto iniciarn como una idea general y se detallarn conforme transcurre el proyecto) sta temporalidad y unicidad diferencia a los proyectos de las operaciones, que son trabajos funcionales en curso permanente o semipermanente y que crean el mismo producto o servicio una y otra vez. La gestin de estos dos sistemas es a menudo muy diferente, por lo que requieren habilidades tcnicas y filosofas diferentes. El primer desafo de la gestin de proyectos es asegurarse de que el proyecto sea entregado dentro de los parmetros definidos. El segundo es la asignacin y la integracin de las entradas necesarias para resolver esos objetivos predefinidos. El proyecto, por lo tanto, es un sistema cuidadosamente seleccionado de actividades definidas para utilizar los recursos (tiempo, dinero, recursos humanos, materiales, energa, espacio, provisiones, comunicacin, calidad, riesgo, etc.) para resolver los objetivos predefinidos .

Gerente de proyecto
La gestin de proyectos muchas veces, la responsabilidad de un individuo. Este individuo raramente participa de manera directa en las actividades que producen el resultado final. En vez de eso se esfuerza por mantener el progreso y la interaccin mutua productiva de las varias partes de manera que el riesgo general de fracasar se disminuya. Un gerente de proyectos es muchas veces un representante del cliente y debe determinar e implementar las necesidades exactas del cliente, basndose en su conocimiento de la firma que representa. La habilidad de adaptar los mltiples procedimientos internos de la parte contratante y la forma de estrechar los lazos con los representantes seleccionados es esencial para asegurar que los objetivos clave de costo, tiempo, calidad y, sobre todo, satisfaccin al cliente, se hagan realidad. Sin importar el campo, un gerente de proyectos exitoso debe ser capaz de visualizar el proyecto completo de principio a fin y tener la habilidad de asegurar que esa visin se haga realidad. Cualquier tipo de producto o servicio - edificios, vehculos, productos electrnicos, software de computadora, servicios financieros, etc. - puede ser supervisado en su implementacin por el gerente de proyectos y su operacin por el gerente de producto.

La tres restricciones tradicionales

Como cualquier empresa humana, los proyectos necesitan ser ejecutados y entregados bajo ciertas restricciones. Tradicionalmente, estas restricciones han sido alcance, tiempo y costo. Esto tambin se conoce como el Tringulo de la Gestin de Proyectos, donde cada lado representa una restriccin. Un lado del tringulo no puede ser modificado sin impactar a los otros. Un refinamiento posterior de las restricciones separa la calidad del producto del alcance, y hace de la calidad una cuarta restriccin. La restriccin de tiempo se refiere a la cantidad de tiempo disponible para completar un proyecto. La restriccin de coste se refiere a la cantidad presupuestada para el proyecto. La restriccin de alcance se refiere a lo que se debe hacer para producir el resultado final del proyecto.

Estas tres restricciones son frecuentemente competidoras entre ellas: incrementar el alcance tpicamente aumenta el tiempo y el costo, una restriccin fuerte de tiempo puede significar un incremento en costos y una reduccin en los alcances, y un presupuesto limitado puede traducirse en un incremento en tiempo y una reduccin de los alcances. La disciplina de la gestin de proyectos consiste en proporcionar las herramientas y tcnicas que permiten al equipo de proyecto (no solamente al gerente del proyecto) organizar su trabajo para cumplir con todas esas restricciones .

Tiempo
El tiempo se descompone para propsitos analticos en el tiempo requerido para completar los componentes del proyecto que es, a su vez, descompuesto en el tiempo requerido para completar cada tarea que contribuye a la finalizacin de cada componente. Cuando se realizan tareas utilizando gestin de proyectos, es importante partir el trabajo en pedazos menores para que sean fciles de seguir.

Costo
El costo de desarrollar un proyecto depende de mltiples variables incluyendo costes de mano de obra, costes de materiales, administracin de riesgo, infraestructura (edificios, mquinas, etc.), equipo y utilidades. Cuando se contrata a un consultor independiente para un proyecto, el coste tpicamente ser determinado por la tarifa de la empresa consultora multiplicada por un estimado del avance del proyecto.

Alcance
Requerimientos especificados para el resultado final. La definicin global de lo que se supone que el proyecto debe alcanzar y una descripcin especfica de lo que el resultado final debe ser o debe realizar. Un componente principal del alcance es la calidad del producto final. La cantidad de tiempo dedicado a las tareas individuales determina la calidad global del proyecto. Algunas tareas pueden requerir una cantidad dada de tiempo para ser completadas adecuadamente, pero con ms tiempo podran ser completadas excepcionalmente. A lo largo de un proyecto grande, la calidad puede tener un impacto significativo en el tiempo y en el costo (o viceversa).

Actividades de la gestin de proyectos

Generalmente los gestores de proyectos son responsables de algunas o todas las siguientes actividades: 1. Redaccin de la propuesta. La propuesta describe los objetivos del proyecto y cmo se llevara a cabo. Incluye estimaciones de costo y tiempo y justifica por qu el contrato del proyecto se debe dar a una organizacin o equipo en particular. Planificacin y calendarizacin del proyecto. Se refiere a la identificacin de actividades, hitos y entregas del proyecto. Estimacin de costos del proyecto. Es una actividad relacionada con la estimacin de los recursos requeridos para llevar a cabo el plan del proyecto. Supervisin y revisin del proyecto. La supervisin es una actividad continua. El gestor debe conocer el progreso del proyecto con los costos actuales y los planificados. Tambin, es normal tener varias revisiones formales de su gestin. Se hace una revisin completa del progreso y de los desarrollos tcnicos del proyecto, teniendo en cuenta el estado del proyecto. El resultado puede dar lugar a una cancelacin. Seleccin y evaluacin del personal. Los gestores, generalmente, seleccionan a las personas que trabajarn en su proyecto. O establecen un equipo ideal mnimo para el proyecto. Redaccin y presentacin de informes. Los gestores son los responsables de informar a los clientes y contratistas sobre el proyecto. Deben redactar documentos concisos y coherentes que resuman la informacin crtica de los informes detallados del proyecto. SOMMERVILLE, IAN (2002), INGENIERIA DEL SOFTWARE, Madrid: Pearson Educacin. 8478290745.

2.
3. 4.

5. 6.

Oficina de Gerencia de Proyectos: Teora y prctica Project Management Office: Theory and praxis Contenido

1. Introduccin 2. Gestin de proyectos y la Oficina de Gerencia de Proyectos o 2.1. Evolucin de la disciplina Gerencia de Proyectos y de OGP o 2.2. Modelos de OGP o 2.3. Funciones de la OGP o 2.4. Implementacin de la OGP 3. Presentacin y anlisis de los estudios de caso o 3.1. Metodologa o 3.2. Motivos para la implementacin de una OGP o 3.3. Papel y funcin de la OGP o 3.4. Porte de la OGP o 3.5. Modelos de OGP o 3.6. Factores facilitadores y restrictivos o 3.7. Instalacin / implementacin de la OGP 4. Conclusiones Referencias

RESUMEN Ha habido un inters creciente por la disciplina Administracin de Proyectos, reflejado por el significativo aumento del nmero de socios del PMI Project Management Institute as como el nmero de profesionales que han buscado la certificacin PMP Project Management Professional. Tambin la PMO - Project Management Office, aqu traducido como Oficina de Gerencia de Proyecto (OGP), ha sido objeto de atencin por empresas que buscan el xito en la administracin de sus proyectos. Sin embargo, hay un conocimiento insuficiente sobre las empresas que ya lo hicieron, cmo ellas estn organizadas y cules resultados han proporcionado. El objetivo principal del artculo es identificar cmo planear, estructurar y facilitar la implementacin de OGPs en las empresas. Estudiar las posibilidades de estructuracin e implantacin de OGPs y proponer recomendaciones para empresas interesadas en el tema, son objetivos especficos. Fue realizada una revisin de la bibliografa sobre el asunto y fueron estudiados cuatro casos empresariales. La investigacin emprica comenz con un modelo que consider la relacin entre la forma de operacin de las OGPs, los beneficios alcanzados con la implementacin y las condiciones sobre las cuales opera. A partir de la comparacin entre la literatura y la prctica verificada, en los casos estudiados, fueron extrados anlisis y conclusiones sobre los motivos para la implementacin de una OGP, los papeles y funciones de la OGP, su tamao, los modelos, factores facilitadores y restrictivos y las formas adoptadas para su implementacin.

1. Introduccin Los proyectos son los vehculos necesarios para los cambios organizacionales emprendidos por las empresas que quieren competir en un mundo con permanentes desafos y de nuevas oportunidades. Ellos exigen la participacin de profesionales y tcnicos que en muchas ocasiones no poseen una formacin adecuada en gerencia de proyectos. En verdad, gran parte de estos profesionales son involucrados en operaciones de rutina de la empresa y ejercen la funcin de gerentes de proyectos apenas con base en la experiencia tcnica adquirida previamente. La implementacin del la gerencia de proyectos (GP) en las empresas requiere el reconocimiento de la disciplina como algo que demanda del practicante habilidades, actitudes y comportamientos especficos. El abordaje de gerencia de proyectos necesita, entonces, de una amplitud profesional. Como individuo, el gerente de proyectos necesita conocer y saber usar las herramientas de gestin de tiempo, costo, enfoque y otras. En el nivel organizacional, es imprescindible conocer el ambiente del proyecto y realizar los esfuerzos necesarios para que los recursos humanos y materiales estn disponibles. Este ha sido el escenario para el crecimiento vertiginoso del rea de gerencia de proyecto. Frame (2001), en conferencia proferida en el Seminario Internacional El desafo de la capacitacin en gerencia de proyecto realizado en So Paulo, el 27/11/2002, trajo informacin reciente que apunta a que en junio de 2001 el PMI Project Management Institute asociacin que congrega profesionales de gerencia de proyectos del mundo, ya tena 80.000 miembros y constaba de 32.000 profesionales certificados. Estos nmeros ganan relevancia cuando comparados con aquellos verificados en las dcadas de 80 y 90 que registraban, respectivamente, 8.000 y 25.000 socios del PMI (Block & Frame, 1998). As como la prctica de la gerencia de proyectos ha crecido, hay tambin una demanda significativa para un mtodo sistemtico de implantacin de las metodologas, tcnicas y herramientas de GP en las organizaciones. La demanda por una gerencia eficaz, la multiplicacin del nmero de proyectos, as como la creciente complejidad de los mismos, son aspectos que justifican la

implementacin de una Project Management Office, aqu traducida como Oficina de Gerencia de Proyecto (OGP). Si por un lado, el inters en la implantacin de OGPs ha crecido, hay poco conocimiento sobre las empresas que ya lo hicieron, como ellas son configuradas y los resultados que han proporcionado. Esta situacin motiv a los autores de este trabajo a investigar el asunto, de modo de traer nuevos elementos para una mejor comprensin de lo que es una Oficina de Gerencia de Proyectos y cmo ese rgano puede ayudar a las organizaciones a obtener xito con los proyectos y en los negocios. Este trabajo busca responder a las siguientes preguntas clave: cmo planear, estructurar y facilitar la implementacin de OGPs en las empresas? Los objetivos especficos del trabajo son: a) estudiar las varias posibilidades de estructuracin de OGPs, observando los factores de xito y aspectos crticos; b) proponer recomendaciones para empresas que vengan a trabajar con el planeamiento, estructuracin e implementacin de OGPs, de modo tal que esa prctica sea xitosa en las organizaciones que actan en el ambiente de proyectos. Se espera elaborar una serie de recomendaciones para la implementacin de OGP que sirvan de parmetro para empresas donde la gerencia de proyectos sea factor de xito para el negocio o en empresas que requieren administrar la complejidad de conducir mltiples proyectos simultneamente. 2. Gestin de proyectos y la Oficina de Gerencia de Proyectos 2.1. Evolucin de la disciplina Gerencia de Proyectos y de OGP La revisin bibliogrfica seal que la disciplina gerencia de proyectos ha pasado por una casi revolucin en las dos ltimas dcadas. Por un tiempo, los proyectos eran administrados de forma ad hoc, o sea, para cada proyecto era designado un gerente que tuviera experiencia tcnica previa en aquel determinado asunto. Sin embargo, los ndices de fallas en proyectos llevaron a cambios progresivos en la forma de dirigirlos. Surge la moderna gerencia de proyectos que se preocupa por mtodos y tcnicas que sean aplicables a proyectos de diferentes portes y complejidad, aunque con un enfoque fuertemente gerencial y no meramente tcnico. Planeamiento, acompaamiento y ejecucin de los proyectos de forma consistente y lgica pasaron a ser vistos como una forma de aumentar el ndice de xito de los proyectos. (Kerzner, 1996). De la misma forma como la disciplina de gerencia de proyectos comenz a ser reconocida como una habilidad especfica, comenzaron a surgir las OGPs, como una manera de proveer una unidad organizacional responsable por procesos de gestin de proyectos. La OGP pasa a ser la casa de los gerentes de proyectos, donde ellos encuentran el respaldo necesario para administrar sus proyectos dentro del plazo, costo y cualidad requeridos, por medio de la utilizacin de mtodos y procesos de planeamiento, acompaamiento y control. Adems de eso, la OGP es responsable por hacer la ligacin entre el gerente de proyecto y la alta administracin, por medio de un sistema de feedback que permite el perfeccionamiento continuo de la disciplina en la organizacin. Este es el concepto de OGP, adaptado de Berstein, S. (2000), adoptado por autores del presente estudio e ilustrado en la figura 1. Figura 1 Concepto de OGP

Fuente: Adaptado de Bernstein, S. (2000) 2.2. Modelos de OGP La literatura apunta una diversidad de modelos y funciones que la OGP puede asumir, dependiendo de la etapa de evolucin de la disciplina en la empresa, del tipo de estructura organizacional (matricial funcional, balanceada, pesada o autnoma), entre otros factores. Hay desde OGPs que tienen la funcin nica de informar el desempeo de los proyectos hasta aquellos que participan de la definicin de las estrategias empresariales y son responsables por el cuerpo de profesionales del rea. La OGP puede tener un foco apenas en procesos internos (planeamiento, gerencia de personas, ejecucin, control de cambios, etc), pero tambin puede responsabilizarse por interfases externas (satisfaccin del cliente, comunicacin con los stakeholders, etc.). Hay tambin diferentes nombres, tales como Oficina de Proyectos, Oficina de Soporte a Proyectos, Centros de Excelencia, etc., pero lo que las distingue son los diferentes grados de autoridad y responsabilidad. Casey & Perck (2001) parten del presupuesto de que no

existe un nico tipo de OGP que atienda a todas las necesidades y que se deba evitar un modelo padrn que pude acabar operando como cualquier otro departamento funcional. Diferentes tipos de OGPs resuelven diferentes problemas. Para escoger el modelo adecuado se debe tomar en cuenta el nivel de madurez de la gerencia de proyectos en la organizacin. El autor describe tres tipos de OGPs, que pueden ser apreciados en la figura 2, y los problemas que cada una de ellas pude solucionar. Figura 2 Modelos de OGP

Fuente: Adaptado de Casey & Peck (2001) Cuando el problema de la empresa es la confusin causada por diferentes tipos de informes elaborados por diferentes gerentes de proyectos, con jergas variadas, la solucin sera la Estacin Meteorolgica. Este tipo de OGP apenas informa la evolucin de los proyectos, pero no intenta influenciarlos. As como una estacin meteorolgica, la OGP informa a los pilotos sobre las condiciones del tiempo, sobre la direccin que los pilotos estn tomando, pero no conduce l mismo el avin, tampoco influencia el vuelo. Su misin es informar. La estacin meteorolgica no est autorizada a decir a los gerentes de proyectos y a sus clientes cmo y qu hacer. Responde a preguntas tales como: cmo est nuestro proyecto? Cunto ya gastamos de nuestro presupuesto hasta aqu? Cules son nuestros riesgos? Este tipo de OGP tambin puede ser responsable por mantener una base de datos con documentos histricos de proyectos y lecciones aprendidas. Por otro lado, cuando la organizacin tienen problemas de entrenamiento de personal (el entrenamiento puede existir, pero no se traduce en aplicacin), metodologas caras y poco utilizadas; altos ejecutivos con poca comprensin o visin equivocada sobre gerencia de proyectos; lecciones aprendidas no utilizadas en nuevos proyectos; uso y cambio constantes de cualquier mtodo y herramientas, la Torre de Control parece ser la solucin ms adecuada. En este caso, el gerente de la OGP da la direccin a los gerentes de proyectos. Cada gerente maneja su avin y tiene responsabilidad por el vuelo, pero debe seguir las instrucciones de la torre de control, particularmente durante el despegue y el aterrizaje. As, los pilotos prestan mucha atencin a la torre de control, pues el avin puede caer si las reglas no son seguidas. La Torre de Control establece la metodologa de gerencia de proyectos, incluyendo gerencia de riesgo, definicin de roles y responsabilidades, comunicacin, gestin de objetivos, lecciones aprendidas y herramientas. Tambin es responsable por la consultora interna, en el sentido de garantizar que la metodologa ser seguida, y por la constante mejora en los procesos. Organizaciones cuyo negocio es hacer proyectos necesitan estar permanentemente atentas a la capacitacin de su personal en gerencia de proyectos. En general, la persona que contrata y trata con los gerentes de proyectos sabe muy poco sobre la funcin. Por otro lado, es fundamental para la empresa que ellos sean bien seleccionados, bien entrenados y que permanezcan en la empresa. La solucin, en este caso, es el Pool de Recursos. La participacin del gerente de una OGP es bastante fuerte. l indica a los gerentes de proyectos cundo entrar en el cockpit y cundo decolar. Igual que en el aire, todos los pilotos deben estar en estrecha consonancia y volando en la misma direccin. Algunos pilotos pueden ser verdaderos ases, otros no tanto, pero el gerente de la OGP es evaluado por el desempeo del pool. Un Pool de Recursos puede ofrecer un conjunto de gerentes de proyectos con habilidades necesarias para administrar los diferentes tipos de proyectos para los cuales fueron designados, as como una supervisin para garantizar que estas habilidades sern efectivamente aplicadas. Este no es un tipo de estructura que basta implementar y ella andar solita. Al contrario, requiere algunos cuidados. El gerente del pool debe ser el responsable por designar los gerentes a los respectivos proyectos y el pool es la nica fuente disponible en la empresa. Los ejecutivos no pueden contratar gerentes de proyectos que no sean del pool o, por lo menos, sin consultar al gerente. El gerente del pool es la autoridad mxima en lo que respecta a sus funcionarios. 2.3. Funciones de la OGP De acuerdo con Rad & Raghavan (2000), cuanto ms complejo es el modelo adoptado, obviamente mayor ser la lista de atribuciones de la OGP. En general, las OGPs son responsables por: a) prestar servicios internos en gerencia de proyectos (entrenamiento, y desarrollo de profesionales, consultora interna, acompaamiento de proyectos crticos, etc.); b) desarrollo / implementacin de mtodos, procesos y medidas de evaluacin (es el guardin de la metodologa de gerencia de proyectos); c) anlisis de mejores prcticas (documentacin de los xitos y fracasos, investigacin externa sobre las mejores prcticas) y, d) ser depositario de la memoria tcnica de los proyectos para que modelos y estimaciones puedan ser usadas por gerentes de proyectos. Adems de estas funciones bsicas, hay una tendencia de que la OGP debe establecer un puente entre la alta administracin y los gerentes de proyectos, de tal forma de alinearlos con las estrategias de negocios.

2.4. Implementacin de la OGP En lo que respecta a la implementacin de la OGP, hay una convergencia entre los autores estudiados, tales como Bridges & Crawford (2001), de que ello debe ser progresivo. La OGP debe comenzar a operar de forma ms sencilla y focalizada, principalmente para mostrar resultados rpidamente. Paulatinamente, sus atribuciones pueden ir sofisticndose, conforme van ganando la confianza del equipo. La cuestin del patrocinio de la alta administracin tambin tiene papel fundamental en la implementacin de la OGP. Las decisiones sobre modelo, porte y atribuciones de la OGP deben llevar en consideracin los factores crticos de xito y fracaso. Una OGP, para obtener xito, debe funcionar como un catalizador, estableciendo lazos internos y transformando las informaciones dispersas en conocimiento organizacional. La oficina debe venir para facilitar y no para complicar las acciones de los gerentes de proyectos. En este sentido, debe ser la guardiana de la metodologa, pero no esclava de ella, evitando el papel de simple auditora. El mayor beneficio de la implantacin de una OGP es hacer las cosas ms fciles. Administrar proyectos es una tarea compleja y cabe a la OGP, por medio de la automatizacin de tareas, del uso de modelos, de adecuada utilizacin de la metodologa, crear una atmsfera positiva y respaldar a los gerentes de proyectos. A partir de este ambiente, es posible realizar proyectos con xito. 3. Presentacin y anlisis de los estudios de caso 3.1. Metodologa Fue adoptado una abordaje cualitativo, que pareci especialmente til frente a las siguientes caractersticas destacadas por Merriam (1998): a) el estudio cualitativo se fundamenta en la ptica de la realidad construida por individuos interviniendo con sus mundos sociales; b) es un esfuerzo para entender situaciones nicas como parte de una situacin particular y su interacciones; c) la preocupacin bsica es entender el fenmeno bajo la perspectiva de los actores y no del investigador; d) usualmente envuelve investigacin de campo; e) emplea estrategia inductiva de investigacin; y f) es ricamente descriptiva, pues enfoca procesos, sentidos y conocimientos. El estudio de caso fue la opcin de los actores en trminos de estrategia de investigacin, pues, de acuerdo con Yin (2001, p. 28), esta es la estrategia mas adecuada cuando se hace una pregunta del tipo cmo por qu sobre un conjunto contemporneo de acontecimientos sobre el cual el investigador tiene poco o ningn control. Estas condiciones parecen perfectamente aplicables al presente trabajo teniendo en vista que el objeto de estudio es el entendimiento de cmo un fenmeno reciente (la OGP) est siendo implementado en las organizaciones. El estudio de caso ha sido extensivamente usado en la investigacin social, especialmente en las disciplinas que poseen una fuerte orientacin hacia la prctica como en la Administracin. Pero, es necesario registrar que el mtodo tiene algunas limitaciones, especialmente por el hecho de ofrecer poca base para generalizaciones cientficas una vez que, para estudiar uno o pocos casos, no se constituye una muestra de la poblacin y, por eso, no hay posibilidad de generalizaciones. En lo que respecta a la seleccin de los casos estudiados, Merriam (op. cit.) enfatiza que, al tratarse de una investigacin cualitativa, el uso de una muestra no probabilstica es lo ms indicado. Por tanto, fue usada una muestra intencional, que consisti en identificar y seleccionar empresas donde fuera posible obtener las informaciones necesarias para el estudio. De esta forma, la investigacin fue hecha junto a cuatro empresas previamente identificadas por los autores del presente trabajo como poseedoras de OGPs o estructura similar, en diferentes sectores de la economa (tabla 1). Los participantes de la investigacin fueron seleccionados en funcin de los conocimientos sobre la metodologa de gerencia de proyectos, as como de las informaciones que disponan sobre la implantacin de la metodologa y de la OGP en la empresa. La identidad de los entrevistados, as como de las empresas, fue protegida, no siendo registrada en el presente estudio. Tal medida es una prctica ampliamente adoptada en estudios cualitativos. La tcnica de recoleccin de datos primarios fue la entrevista semi-estructurada, por posibilitar preguntas ms flexibles y por dejar emerger la visin del entrevistado. Fue elaborada una gua con una lista de preguntas / asuntos a ser explorados. Las entrevistas fueron grabadas para asegurar que todo lo que era dicho fuera preservado para anlisis. Tambin fueron utilizados el anlisis documental para el levantamiento de datos secundarios . 3.2. Motivos para la implementacin de una OGP Los datos colectados parecen indicar una relacin directa entre el grado de sensibilizacin de la empresa en relacin al tema OGP y el grado en que los proyectos son actividad fin para las organizaciones investigadas. O sea, cunto mayor el grado de dependencia financiera de la empresa en relacin a sus proyectos, mayor la preocupacin por la eficiencia de los procesos gerenciales. Empresas como la Gama-Telecom y la Delta T.I. parecen estar en un nivel superior en trminos de la integracin entre los proyectos, mediante la utilizacin de la OGP, exactamente por el hecho de existir una gran dependencia entre los resultados de los proyectos y los resultados de los negocios. Adems de este aspecto, hay otros factores motivadores identificados:

Necesidad de la garanta de la utilizacin de una metodologa de GP y la necesidad de la homogenizacin del mtodo de gerencia de proyecto. La OGP est siempre relacionada a la difusin de los conceptos y de la cultura gerencial de proyectos. En los casos estudiados y en la literatura son frecuentes las referencias a la OGP como medio para el desarrollo de una metodologa de GP en la empresa. La consolidacin de los resultados de varios proyectos fue una motivacin encontrada mucho ms en la literatura de que en los casos estudiados. En el caso de la Alfa-Areo es citada una relacin entre necesidad de una OGP y la optimizacin de los procesos de negocio y de los resultados de la empresa, pero la OGP es todava embrionaria. En la Delta T.I., los indicadores de los proyectos son consolidados por la OGP, pero eso es ms una atribucin operacional que surge del desdoblamiento del desarrollo de la OGP que de un motivador para su implantacin. De esto se pude inferir que la cuantificacin de los beneficios de una OGP y de su impacto en la racionalizacin de los recursos de proyectos no es comn en la prctica, a pesar de ser considerado importante por la literatura. La necesidad de controlar varios proyectos simultneos es un motivador importante, tanto para la literatura como en los casos donde proyectos son directamente responsables por los ingresos de la empresa. Desde el punto de vista de la literatura en cuanto a los casos estudiados, la gestin de conocimiento en GP es considerado una atribucin importante de la OGP, una vez que ese tipo de estructura facilita el trueque de experiencias entre proyectos y documenta las lecciones aprendidas. Este factor est directamente relacionado al grado de sensibilizacin del tema en la organizacin. Uno de los motivadores que aparecen con frecuencia en la literatura es el papel de mediadora de la OGP en la posible racionalizacin de recursos de la empresa. En el caso de Gama-Telecom, a pesar de que los recursos sean administrados/asignados por la OGP, este beneficio no es claramente percibido. Tampoco fue percibido en los dems casos, donde las OGPs son ms compactas. Tal vez esta preocupacin pertenezca a una etapa ms avanzada de OGP, donde ella venga a determinar los recursos de los proyectos. Este beneficio es percibido de forma indirecta, denunciando que decisiones sobre implementacin de OGP pueden ser tomadas sin un anlisis de viabilidad y retorno (business case) conveniente, o lo que de cierta forma pude llevar a una implementacin ad hoc o a una posicin polticamente ms dbil de OGP en la empresa. En uno de los casos, Gama-Telecom, la OGP fue motivada por la necesidad de homogenizacin de la metodologa para la ejecucin de proyectos. La literatura sobre el tema no recomienda este abordaje debido al potencial de resistencias que ella pueda traer, frente a la percepcin de intervencin de la OGP en el proyecto. La distincin entre las metodologas de implementacin de proyecto y de gerencia de proyectos es importante para el xito de la OGP. Es importante, todava, reconocer las prcticas ya existentes, perfeccionndolas. O sea, en lo que respecta a la metodologa, una estrategia bottom-up es ms recomendada.

3.3. Papel y funcin de la OGP Las organizaciones de gerencia de proyecto de los casos estudiados pueden ser divididas en dos tipos: las OGPs con foco en implementar proyectos para la empresa, cuyo equipo de la oficina es formada por especialistas de las reas funcionales y que trabajan de manera autnoma y auto-suficiente en conocimiento y recursos (Alfa-Areo y Beta-Qumica); y las OGPs, dentro del concepto de este trabajo, como integradora de varios proyectos de la empresa, independientemente de dnde estn los especialistas y los recursos para el desarrollo del proyecto (Gama-Telecom y Delta T.I.). Considerando esta diferenciacin, reforzada por el hecho de la Alfa-Areo est buscando viabilizar un nuevo modelo de oficina de programas, con un papel ms integrador, podemos consolidar el papel y funciones de una OGP, mediante anlisis de los casos observados, de la siguiente forma: Integracin de diversos proyectos por la promocin de la comunicacin entre los equipos de proyecto; Guarda de la metodologa de gerencia de proyecto y principal vehculo de divulgacin de la disciplina; Administradora del conocimiento en GP, por medio de la documentacin de las lecciones aprendidas y coaching. Acompaamiento de la satisfaccin de los clientes finales del proyecto; Responsable por la adherencia de los GPs a la metodologa; Garanta del intercambio de experiencias / conocimientos entre los proyectos; Acompaamiento de indicadores bsicos de proyectos (previsto vs. realizados en trminos de amplitud, costo y tiempo); Acompaamiento de indicadores de proyectos que tengan impacto en el desempeo del negocio; Mediacin de conflictos en la estructura matricial.

Los puntos arriba demuestran que las OGPs estudiadas poseen atribuciones de soporte a los proyectos, aunque no ejerciendo atribuciones de control y de determinacin de los equipos de proyecto. Esta posicin de facilitadora en comparacin con el potencial de atribuciones listadas por la literatura puede indicar que, a pesar de no ser planeado de esta forma, las OGPs pasan por un proceso de ganar experiencia, agregando funciones y responsabilidades. Esta forma de introduccin de OGPs en la organizacin debe reducir los riesgos asociados y mejorar la eficacia de la inversin. 3.4. Porte de la OGP El tamao de la OGP varia conforme a la necesidad y a la complejidad de los proyectos, as como de acuerdo con las funciones y responsabilidades a ella asignada. En los casos estudiados fueron encontradas OGPs con 60 funcionarios (Alfa-Areo); 34 funcionarios (Beta-Qumica); 94 funcionarios (Gama-Telecom) y 6 funcionarios (Delta T.I,) demostrando que no hay ninguna

convergencia en cuanto a este aspecto en los casos estudiados. Gama-Telecom y Delta T.I. son polos opuestos, a pesar de tener modelos de OGPs conceptualmente similares. El tamao es mayor cuando los gerentes de proyectos son vinculados a la OGP, como en el caso de la Gama-Telecom, pero en este punto no existe una mejor prctica debido a la variedad de alternativas como las presentadas en la literatura y confirmada por los casos estudiados. 3.5. Modelos de OGP OGPs, conforme el concepto de este trabajo, fueron observadas como siendo entidades organizacionales definidas, con equipo y procesos propios, as como con autonoma en la organizacin de proyectos. Evidencias de los casos y de la literatura indican que es importante para la sobrevivencia de las OGPs su estructuracin en una entidad autnoma, permanente o transitoria, con sus objetivos alineados a las estrategias de la empresa. La oficina de la Beta-Qumica se escapa de este modelo por estar ms prxima a un departamento de ingeniera que a un elemento organizacional dedicado a la integracin entre varios proyectos. La estructura interna de la OGP depende de las atribuciones de la misma. El equipo debe tener fuerte foco en gerencia de proyecto y ser compuesta por especialistas en diversos procesos de gerencia de proyecto. En el caso de la Delta T.I. el foco est en el control de los proyectos y produccin de informes de seguimiento. En el caso de la Gama-Telecom el foco est en la metodologa y la administracin de recursos (gerente de proyecto). Conforme el concepto de OGP evoluciona, se espera que nuevas capacidades vengan a ser integradas. La literatura resalta la importancia de la formacin de equipos de OGP en gerencia de proyectos. Tambin es consenso entre los casos estudiados y la literatura que es importante un liderazgo nico para la OGP. Se observa que las atribuciones de la OGP varan tambin cuando se considera el nivel jerrquico en que ella se posiciona. Aunque todos los modelos observados le dieron nfasis al soporte de proyectos, fue posible encontrar algunas distinciones. Las OGPs de la Gama-Telecom y de la Alfa-Areo estn en un nivel bastante alto en la jerarqua, reflejando el papel ms estratgico que deben asumir, mientras que en la Delta T.I. est en un nivel ms operacional, denotando el papel de integrador de informaciones y no de centro de toma de decisin. La literatura indica que el patrocinio de un nivel ms elevado en la organizacin es factor de xito para la implementacin de la OGP. En los casos observados, existe una relacin directa entre el grado de patrocinio de liderazgo senior y el proceso de implementacin de la OGP. La empresa Gama-Telecom atraves fases de turbulencia en el proceso de implementacin de la OGP, especialmente en cuanto a su influencia sobre reas de negocio y su papel ante los proyectos de la organizacin. Tal hecho puede ser atribuido a los cambios de patrocinadores a lo largo del proceso. Algunos aspectos que tornan imprescindible la participacin del lder senior en el proceso de implementacin de la OGP merecen ser considerados en esta discusin: la dificultad en justificar con cifras la implementacin de la OGP; la percepcin de que los beneficios de la implementacin de una OGP son a largo plazo, mientras que el aumento de la carga burocrtica es inmediato, debido a la aplicacin formal de metodologas de GP; un tercer aspecto est constituido por los conflictos que deben ser administrados a partir de la introduccin de un nuevo grupo que disputar el poder con grupos ya establecidos en la organizacin.

La discusin del modelo ms adecuado de la OGP debe considerar otro aspecto que es provocador de conflictos en la implementacin. Es importante que sea hecha una distincin clara entre metodologas de Gerencia de Proyectos (e.g., aquellas desarrolladas con base en el PMBOK), aplicables a proyectos de cualquiera naturaleza, y la metodologa de implementacin de un proyecto especfico, aplicable a apenas un tipo de proyecto y relacionada a una solucin particular. La OGP debe tratar varios proyectos, ofreciendo una metodologa de GP que sirva de gua para los equipos, sin con eso interferir en el papel de los especialistas en metodologas especficas de cada proyecto. Caso contrario, la OGP puede sufrir resistencias de los equipos de proyectos, uno de los principales clientes internos. As, en la definicin de modelo de la OGP, el grado de influencia de la misma en cada proyecto debe ser cuidadosamente estudiado. 3.6. Factores facilitadores y restrictivos Los factores que facilitan o restringen la implementacin de una OGP son bsicamente los mismos que estn presentes en cualquier proceso de cambio organizacional. Estos factores, de acuerdo con los casos estudiados y con la literatura, envuelven esencialmente a la dimensin de personas en la organizacin. La implementacin de una OGP es un proyecto esencialmente organizacional, independiente del espacio fsico necesario o de las herramientas tecnolgicas que puedan ser adoptadas. Existen resistencias a la implementacin de las OGP, informadas en los casos, debido a la sensacin de prdida de poder por parte de las reas funcionales y por la actuacin del elemento organizacional normalizador de los procesos gerenciales. Otro factor restrictivo observado fue la falta de apoyo o patrocinio de la alta direccin de la empresa, una vez que l afecta el ritmo de la implementacin de la OGP. Gerentes de proyecto resisten tambin a la implementacin, por percibir a la OGP como un cambio que introduce procesos burocrticos y que promueve una intervencin en sus proyectos. Hay, todava, la necesidad de inversiones en infraestructura y capacitacin, pero como los beneficios de corto plazo son difciles de ser demostrados, el valor del esfuerzo de implementacin de la OGP puede no ser percibido por la empresa. Otro factor restrictivo observado es la poca atencin dada a la comunicacin a lo largo

del proceso, lo que genera desinformacin y, consecuentemente, expectativas infundadas y conceptos equivocados referentes a las atribuciones, responsabilidades y posibilidades de xito de la OGP. A partir de los casos estudiados, hubo la percepcin de que el proceso de implementacin no fue coordinado, mas bien compuesto de acciones no relacionadas. Aparentemente, el hecho de que las acciones fueron tomadas conforme demandas de urgencia, puede demostrar el origen de un factor restrictivo. Las personas de la organizacin no consiguen ver los objetivos finales y el enfoque de la implementacin de la OGP. Esto qued evidenciado, principalmente, en el caso de la empresa Gama-Telecom. Factores facilitadores estn directamente ligados al grado en que se encuentra la organizacin en trminos de la utilizacin de los procesos de gerencia de proyectos, unidos al grado de madurez en estos procesos. Cuanto ms desarrollados los conceptos de GP en la empresa, ms profesionales directamente impactados por su implementacin percibirn los beneficios de una OGP para la organizacin. Estn tambin relacionados a la forma de administrar las expectativas en relacin a la OGP y a la forma de comunicar los xitos y la evolucin de implementacin. Cuando los ingresos de la empresa estn directamente ligados a proyectos, acciones como la implementacin de una OGP, que mejora la eficiencia de los proyectos y, por tanto, los resultados del negocio, son ms aceptadas en la organizacin, o gozan de mayor prestigio y visibilidad. El enfoque en una implementacin que considere la satisfaccin de las necesidades inmediatas de los gerentes de proyectos auxilia la venta interna de un proyecto de implementacin de OGP, pues puede volver visibles los primeros resultados. El papel de la educacin y capacitacin de los equipos de proyecto en GP es muy importante en el inicio del proceso. La OGP debe actuar como socios de los equipos antes de exigir resultados o aplicaciones de metodologas de GP. Fue as con los dos casos ms consistentes de este estudio: la empresa Gama-Telecom y la empresa Delta T.I. La literatura cita el papel de la educacin y capacitacin como una atribucin de la OGP pero no resalta la importancia de ese papel en los primeros pasos de una implementacin . 3.7. Instalacin / implementacin de la OGP Todos los casos estudiados, con excepcin de la empresa Beta-Qumica, indican que la implementacin por fases es el mejor abordaje. La literatura tambin refuerza que la OGP debe evolucionar en sus atribuciones y complejidad, iniciando con un modelo de informe de resultados, consolidacin de las informaciones, captacin de experiencias y diseminacin de la cultura de OGP, pudiendo evolucionar para un modelo ms complejo de gerencia de recursos para los proyectos o la administracin de portafolio. Dos dimensiones de esta evolucin deben ser consideradas: la del aumento de atribuciones y complejidad, que parece ser consenso, y la de cmo la OGP se debe instalar fsicamente dentro de la estructura organizacional. Siendo una entidad organizacional autnoma, como ya fue discutido, la OGP debe tener su equipo, para despus elaborarse los detalles de su actuacin, o debe la OGP tener sus procesos, papeles y responsabilidades determinados para despus tener sus reglas de actuacin elaboradas o se deben detallar las reglas de actuacin para despus ser constituida? La literatura parece privilegiar el segundo abordaje y la prctica observada, la primera. Si por un lado establecer los procesos, niveles de servicio, interfaces con reas funcionales, etc., de antemano parece ser ms seguro, permitiendo una amplia discusin de los principios que orientarn la implementacin de la OGP, por otro, el tiempo para implementacin es mayor y los xitos de corto plazo demorarn a aparecer en medio a una discusin conceptual. La prctica trajo evidencias de que la implementacin sin el debido planeamiento puede hacer que las resistencias sean grandes. As, el abordaje que parece ser ms apropiado tiene dos direccionamientos: discusin de las directrices bsicas de la OGP e implementacin de la OGP como un proyecto organizacional: a) discusin de las directrices bsicas de la OGP: deben ser considerados factores como misin, objetivos, relaciones con los objetivos estratgicos de la empresa, organizacin inicial, forma de comunicacin y participacin de personas clave, indicacin del gestor de la OGP, equipo inicial e interfases. Una vez decididas estas cuestiones el funcionamiento de la OGP podr iniciarse. Este equipo inicial tendr como atribucin conducir el proyecto de implementacin de la OGP. b) implementacin de la OGP como un proyecto: se debe tomar en consideracin la definicin de enfoque, plazo y presupuesto. El planeamiento podr contemplar: capacitacin del equipo de OGP en GP; participacin de los gerentes de proyecto en el esfuerzo de implementacin; diagnstico del grado de madurez de la empresa en GP; indicadores que permitan monitorear la evolucin de la OGP en su implementacin; definicin de prioridades y definicin de proyecto piloto para testar conceptos y obtencin de resultados de corto plazo; etc. Despus del trmino del proyecto piloto, la OGP debe estar operacional para todos los proyectos y las atribuciones de los miembros de su equipo debe estar dirigida al soporte de los proyectos en afuncionamiento. El surgimiento espontneo de la OGP dentro de las empresas, como consecuencia de demandas urgentes de mayor eficacia en GP, diverge de lo propuesto en la literatura de un abordaje planeado para la implementacin. La urgencia de la respuesta, dada la dinmica de los negocios y la demanda por resultados, se sobrepone a un anlisis ms cuidadoso, inclusive de la propia pertinencia de la OGP para la organizacin. En la mayora de los casos observados no existe, todava, un histrico comprobando la eficacia de la OGP, pues los resultados de corto plazo no fueron percibidos por la empresa o no pudieron todava ser cuantificados de manera sistemtica. Excepto en la Delta T.I., que ha observado que los proyectos han sido finalizados a un costo menor y con menos atrasos. Para que los beneficios puedan ser demostrados, falta agregar en la literatura conceptos que son complementarios a la OGP y que puedan ayudar mucho a la comprensin o la implementacin del mismo, tales como gerencia del cambio organizacional, centro de servicios compartidos y

gestin del conocimiento. Estas disciplinas, asociadas a los conceptos de gerencia de proyecto, pueden ampliar bastante la comprensin y enriquecer la visin sobre la OGP, desviando su enfoque tcnico para el gerencial. Esto facilitara el relacionamiento de los beneficios de la OGP con los resultados de negocio y apunta al futuro de la OGP 4. Conclusiones A partir de la comparacin entre la literatura y la prctica verificada en los casos estudiados, fue posible tejer una serie de anlisis presentados en el captulo anterior. Las conclusiones obtenidas y que ahora son relatadas revelan lo que fue posible comprender respecto del fenmeno OGP. La demanda por una gerencia eficaz, la multiplicacin del nmero de proyectos, as como la creciente complejidad de los mismos, son aspectos que justifican la implementacin de una OGP. Pero, cmo planear, estructurar y facilitar la implementacin de OGPs en las empresas? Para responder a esta pregunta, los autores, adems de la realizacin de la investigacin bibliogrfica, estudiaron cuatro empresas previamente identificadas como poseedoras de OGP o estructura similar, en diferentes sectores de la economa: aeroespacial, telecomunicaciones, tecnologa de la informacin e industria qumica. Tanto en la literatura cuanto en la investigacin, se constat una gran diversidad de modelos y funciones que la OGP puede asumir, dependiendo del grado de evolucin de la disciplina de gestin de proyectos en la empresa, de cun intensiva la empresa es en desarrollo de proyectos, del tipo de estructura organizacional, entre otros factores. Hay desde OGPs que tienen la nica funcin de informar el desempeo de los proyectos hasta aquellas que participan de la definicin de las estrategias empresariales y son responsables por el cuerpo de profesionales del rea. La OGP pude tener un enfoque apenas en procesos internos (planeamiento, gerencia de personas, ejecucin, control de cambios, etc.), pero tambin puede responsabilizarse por interfases externas (satisfaccin del cliente, comunicacin con los stakeholders, etc.). A pesar de esta variedad, se puede decir que, en general, las OGPs son responsables por: a) prestar servicios internos en gerencia de proyectos (entrenamiento y desarrollo de los profesionales, consultora interna, etc.); b) desarrollo / implementacin de mtodos, procesos, herramientas y medidas de evaluacin de proyectos; c) anlisis de mejores prcticas (documentacin de los xitos y fracasos, investigacin externa sobre las mejores prcticas); d) repositorio de la memoria tcnica de los proyectos y de las lecciones aprendidas para que modelos y estimaciones puedan ser usadas por los gerentes de nuevos proyectos. Tan importantes cuanto el formato, funciones u organizacin de la OGP parecen ser las barreras polticas a ser superadas, principalmente las referentes a conflictos tpicos de la estructura matricial, como el doble comando. La adopcin de la OGP pasa por definicin de patrones, procedimientos, procesos, formatos comunes a diversos proyectos. Esto implica la elaboracin y utilizacin de medios formales de comunicacin y documentacin. Resistencias pueden venir de all si los beneficios no fueran bien comprendidos. Delante de este cuadro, la cuestin del patrocinio de la alta administracin pasa a tener un papel fundamental en la implementacin de la OGP. La implementacin de una OGP en una organizacin debe estar alineada con las estrategias de negocios de la empresa, pues los proyectos son formas de implementacin de estas estrategias y, cuanto ms eficaz su administracin, ms temprano los beneficios esperados para el negocio podrn ser conseguidos, y con el menor gasto de recursos. Es consenso entre las empresas investigadas y la literatura que alguna rea dentro de la empresa deba ser responsable por introducir y garantizar la utilizacin de metodologas de GP. Cada caso requiere un estudio de viabilidad que considere el grado de madurez en gerencia de proyectos, impacto de los proyectos en los resultados del negocio, complejidad de los proyectos, grado de soporte en la organizacin, expectativas con relacin a la OGP y los beneficios que ella puede generar. Con una clara demostracin de los beneficios y un abordaje planeado como un proyecto, los conceptos envueltos pueden ser mejor comprendidos y los conflictos en la implementacin de la OGP puede ser minimizados o mejor administrados. La OGP trae la necesidad de mayor transparencia en gerencia de proyectos y una relativa prdida de poder por parte de los gerentes de proyectos. Por otro lado, es tambin una forma de valorizacin de la carrera de gerente de proyectos, que pasa a ser reconocida y a recibir un tratamiento que considera su especificidad. Tambin est presente la nocin de que hay una mayor burocratizacin de los procesos de gerencia. La medida cierta entre una dosis de poder y normalizacin de procedimientos debe ser alcanzada. Sin embargo, en la mayora de los casos observados no existe, todava, un histrico comprobando de la eficacia de la OGP, pues los resultados todava no han podido ser cuantificados de manera sistemtica. Un punto clave, por tanto, parece ser la necesidad de creacin de un mtodo para el desarrollo de la justificacin econmica y demostracin de los beneficios de la OGP que ayude a las empresas que vean a la OGP como una forma de mejorar la eficacia de la gerencia de proyectos.

Referencias

BERNSTEIN, Sally (2000). Project offices in practice. Project Management Journal. December, vol. 30, no. 4, pp. 4-7. BLOCK, Thomas R. & FRAME, J. Davidson (1998). The Project Office - a Key to Managing Projects effectivelly. New York, Crisp Publications. _________ (2001). Todays Project Office: gauging attitudes. PM Network, August, pp. 51-53. BRIDGES, Dianne N. & CRAWFORD, J. Kent (2000). How to star-up and rollout a Project Office. Proceedings of the Project Management Institute Annual Seminars & Symposium. Houston, 7 a 16 de septiembre. CASEY, W. & PECK, W (2001). Choosing the right PMO setup. PM Network, February, pp. 40-47.

FRAME, D (2001). Project Management Competence: A Road to Successful Solutions. Ponencia realizada en el Simpsio Internacional O desafio da competncia em gerenciamento de projetos. So Paulo, PMI/SP, 27-Nov. KERZNER, Harold (1996). The Growth and Maturity of Modern Project Management. Project Management Institute. Papers Presented - 27th Annual Seminar. Boston, Massachusetts. MERRIAN, S (1998). Qualitative research and case study applications in education. 2 ed. San Francisco : Jossey-Bass. RUBENSTEIN, A. H (1980). Um paradigma para o delineamento de problemas organizacionais. Miami Meeting of the Institute of Management Sciences, noviembre, 1976. Traduo de SBRAGIA, R., FEA/USP. YIN, Robert K (2001). Estudo de caso: planejamento e mtodos. Porto Alegre, Ed. Bookman.

Construyendo una PMO: Los procesos

Continuando con la serie de administracin de proyectos tenemos que dejar claro que las PMO son un grupo de servicios dentro de la empresa y que en muchas ocasiones puede ser percibido como no productivo o de poco valor, algo as como las reas de soporte. Sin embargo tiene la carga adicional de ser la encargada de las no tan entusiastas formas, metodologas y "burocracia" que esto produce. La mayora de las personas desean que su trabajo tenga significado, xito y ser parte de un gran equipo. Nuestro trabajo es armar todas las piezas para que este sea el caso. Una forma de lograr esto es tratar a la PMO como un grupo de servicios profesionales externo. El primer componente de profesionalismo es la competencia. Uno debe tener la capacidad y habilidad de realizar el servicio o producto requerido para ser un profesional. Si no podemos hacer el trabajo entonces muy seguramente no duraremos mucho. El siguiente componente es la actitud. Un profesional no hace lo que hace slo por el dinero, l se compromete y tiene cuidado en lo que hace. Finalmente los profesionales tienen carcter. Este es un conjunto de valores clave que se demuestran consistentemente por sus acciones. Si los clientes no pueden confiar en nosotros estamos en problemas y seremos poco efectivos. As que una vez que tengamos a la gente correcta lo siguiente es continuar con los procesos. Lo primero es iniciar con una serie de pautas y valores bsicos. Estos valores y reglas no se pueden romper o melear si no es que queremos caer en inconsistencias, lo cual nos lleva a prdida de confianza y finalmente credibilidad. Algunos ejemplos de valores pueden ser el trabajo de equipo, compromiso a aprender y mejorar continuamente, seguir los estndares, calidad, satisfaccin del cliente, comunicacin, etc. Estos valores son diferentes y varan segn la empresa, pero lo importante es mantenernos consistentes con ellos. La implementacin y administracin de una organizacin profesional implica tres aspectos: El primero es que el profesionalismo requiere una serie de estndares para el comportamiento, rendimiento, aprendizaje, calidad, comunicacin y servicio. El segundo es que queremos que el personal asociado a la PMO tenga el mismo entendimiento de los valores y estndares definidos. Este entendimiento slo pude lograrse a travs de la combinacin de entrenamiento, educacin, direccin, consejo y experiencia. En esto asumimos que el personal realmente quiere aprender a ser ms eficiente y efectivo, y que est dispuesto a dedicarle tiempo y esfuerzo a esta tarea. El tercero, como todo en la vida, es que este profesionalismo debe ser administrado. El avance y rendimiento debe ser revisado realizando ajustes y motivando la mejora. Estas actividades quedan dentro del alcance de la administracin, lder de proyecto y finalmente de la PMO. Al crear una PMO de seguro estamos esperando una serie de procedimientos para la administracin de proyectos. La verdad es que existen una gran variedad de mtodos y procedimientos, muchos ms de los que pudiramos imaginar. Cada uno de estos mtodos viene con sus documentos, entregables y una serie de estndares de todo aquello que se debe incluir. As que, cmo podemos determinar qu incluir y qu no? Cul mtodo funciona mejor y de qu manera? Existe un consejo universal para todo esto y es que debemos empezar en pequeo. Ya sea que estemos empezando desde cero o partiendo de algn mtodo que no hemos podido seguir correctamente. No debemos tratar de inundar a la organizacin con reglas, formas, calendarios, listas de verificacin, minutas de reuniones, etc. De tenerse estndares previos para la administracin de proyectos stos deben revisarse, y negociar cuidadosamente con quienes los siguen, los cambios necesarios para hacerlos ms eficientes. Debemos poner atencin especial a los objetivos de cada tarea y proceso. Hay que tomar lo que tenemos y descomponerlo en sus partes esenciales para as poder ver como se reagrupa y se sigue. Aqu debemos ser cuidadosos con las personas que ya la han invertido tiempo y esfuerzo al proceso anterior, aunque no haya funcionado del todo bien, no queremos ser percibidos como destructores de la "vaca sagrada".

En fin, esta entrada no pretende dar una descripcin de los procesos que deben seguirse para construir una PMO, sino debido a la variedad de mtodos y estndares que existen, es ms una serie de reflexiones sobre los puntos en los que debemos poner mayor cuidado.

PMO: Un nuevo enfoque de Gestin de Proyectos

La gestin tradicional de proyectos, utilizada actualmente en muchas empresas, se puede calificar en mayor o menor grado como poco integrada. La ms comn y evidente iniciativa de integracin, y en la mayora de casos la nica, es la financiera va el presupuesto del periodo. Si existe disponibilidad, el proyecto generalmente tiene luz verde, de otra forma, puede quedar pospuesto o eliminado, sin importar su potencial impacto estratgico futuro. As mismo, muchos proyectos que en su momento, estuvieron dentro de presupuesto, demuestran ser a largo plazo, de poca utilidad y/o divergentes con el rumbo que la empresa decidi tomar durante dicho periodo. Este enfoque tradicional con limitada integracin, presenta debilidades adicionales al momento de dar seguimiento y cuantificar de una manera real y estandarizada el impacto individual de cada una de las iniciativas. Las organizaciones suelen perder de vista los recursos de personal e insumos que cada proyecto finalmente consume, incrementando su costo final y/o reduciendo los beneficios esperados. Estadsticas indican que el 90% de proyectos manejados con un enfoque de gestin no integrado, sufren algn ajuste significativo en sus objetivos originales de tiempo/costo/calidad. Un nuevo enfoque La Oficina de Gestin de Proyectos (Project Management Office) nace formalmente durante la dcada pasada, producto del desarrollo de modernas herramientas y preceptos de gestin de proyectos para profesionalizar, automatizar y consolidar su manejo. La funcin principal de esta oficina es la de ser un elemento integrador entre el negocio y los diferentes proyectos de la empresa (Fig 1), consolidando iniciativas individuales en un solo portafolio; cuantificable, de fcil seguimiento y alineado a la estrategia de largo plazo de la organizacin. La PMO provee de herramientas, metodologas y estructuras comunes para todo el portafolio de proyectos, permitiendo estandarizar la evaluacin/cuantificacin de resultados de los proyectos y el flujo de informacin entre las diferentes reas involucradas y el Comit Directivo de la empresa (Fig 2). El trabajo de la oficina de gestin ayuda a identificar, evaluar y mitigar riesgos potenciales para el xito de las iniciativas, brindando direccin y balanceo de recursos (humanos e insumos) en todo el portafolio de proyectos, asegurando resultados exitosos integrales y no solo iniciativas aisladas. Beneficios de implementar una PMO La oficina de gestin de proyectos (PMO) genera oportunidades de mejora gracias a su visin de portafolio, as como el control, mtricas y uso balanceado de recursos que implica. La metodologa de PMO permite a la organizacin contar con un criterio unificado para evaluar y cuantificar proyectos, permitiendo visualizar su prioridad, impacto y alineacin estratgica real, incrementando la confianza para la toma de decisiones y especialmente motivando la generacin de nuevas y ms ambiciosas iniciativas. Una PMO requiere profundizar en las capacidades de manejo y gestin de proyectos de la empresa introduciendo de manera permanente, conceptos y metodologas de vanguardia. Esto genera un escenario ideal para el incremento gradual en la madurez, sofisticacin y consistencia de los proyectos (Fig 3), implicando a la vez mayores beneficios econmicos a largo plazo. Para terminar, los beneficios que una PMO brinda a una empresa se pueden resumir en 3 grandes puntos. El primero es el introducir mejoras en el Gobierno Corporativo, ya que facilita la toma de decisiones y control organizando los proyectos en un portafolio priorizado. El segundo es el optimizar la Estructura Organizacional, definiendo asignaciones de recursos, roles y responsabilidades de forma clara y balanceada. Finalmente, introduce mejoras en la Medicin y Seguimiento de Proyectos, proveyendo de herramientas adecuadas para definir metas comunes y evaluar de manera objetiva el desempeo y beneficios que cada proyecto aporta a la empresa.

La gestin de Proyectos ha existido desde tiempos muy antiguos, histricamente relacionada con proyectos de ingeniera de construccin de obras civiles (como los proyectos de ingeniera hidrulica en Mesopotamia, donde entraban en juego la logstica o la creacin de equipos de trabajo, con sus categoras profesionales definidas, o la cultura ingenieril desarrollada por el Imperio Romano, donde aparece el control de costes y tiempos y la aplicacin de soluciones normalizadas, como por ejemplo en la construccin de una calzada), y en campaas militares, donde tambin entran en juego muchos elementos de gestin (identificacin de objetivos, gestin de recursos humanos, logstica, identificacin de riesgos, financiacin, etc.). Pero es a partir de la Segunda Guerra Mundial cuando el avance de estas tcnicas desde el punto de vista profesional han transformado la administracin por Proyectos en una disciplina de investigacin. Se puede definir PROYECTO como un conjunto de actividades interdependientes orientadas a un fin especfico, con una duracin predeterminada. Completar con xito el Proyecto significa cumplir con los objetivos dentro de las especificaciones tcnicas, de costo y de plazo de terminacin. A un conjunto de Proyectos orientados a un objetivo superior se denomina PROGRAMA, y un conjunto de Programas constituye un PLAN, como corresponde generalmente a los grandes Planes Nacionales. Todo proyecto1 tiene tres facetas o aspectos diferentes que es necesario armonizar para la consecucin del resultado deseado: Dimensin tcnica: es necesario aplicar los conocimientos especficos de cada rea de trabajo, cumpliendo con una forma de trabajar y unos requisitos (el "know how") que cada profesin impone. Es de sentido comn que es necesario disponer de los conocimientos adecuados para resolver el problema en cuestin o realizar la obra encomendada. Pero la importancia de esta faceta tcnica no debe eclipsar el resto de aspectos que intervienen en la consecucin de un proyecto, y que otorgan a esta actividad de una trascendencia y complejidad mayores Dimensin humana: un proyecto es un complejo entramado de relaciones personales, donde se dan cita un gran nmero de intereses a veces contrapuestos. A las inevitables diferencias que surgen por ejemplo entre el jefe de proyecto y cliente o proveedores, hay que resear las disputas internas a la organizacin que surgen a la hora de repartir los recursos de que se dispone, pues son varios los proyectos que se pueden estar llevando a cabo paralelamente en dicha organizacin. Variable gestin: con este trmino, adoptado por Octave Gelinier, se hace referencia a algo que a veces se menosprecia porque no es tan espectacular o visible como otros elementos pero que es el catalizador que permite que el resto de los elementos se comporten adecuadamente2. De gestionar bien o mal depende en gran medida el xito o no de la operacin.

Vamos a tratar aqu tres elementos fundamentales de la gestin de proyectos, como son: Elementos de Planificacin y Control:
- Etapas de un proyecto - La oferta - Los objetivos - Ciclo de vida - Identificacin y descripcin de actividades - Los recursos - Plazos y costes - Tcnicas de programacin de actividades - La toma de decisiones La gestin de los Recursos Humanos - El equipo de trabajo - Perfiles y estructura - Conflictos El Jefe de Proyecto.

PLANIFICACIN

La planificacin de un proyecto debe afrontarse de manera adecuada para que al final del mismo se pueda hablar de xito. No se trata de una etapa independiente abordable en un momento concreto del ciclo del proyecto. Es decir, no se puede hablar de un antes y un despus al proceso de planificacin puesto que segn avance el proyecto ser necesario modificar tareas, reasignar recursos, etc. Se debe tener claro que si bien s podemos hablar de una "etapa de planificacin", llamada as porque aglutina la mayor parte de los esfuerzos para planificar todas las variables que se darn cita, cada vez que se intenta prever un comportamiento futuro y se toman las medidas necesarias se est planificando. Encontramos dos grandes fases en las que la planificacin cobra el mximo protagonismo. La primera es necesaria para estudiar y establecer la viabilidad de un proyecto, ya sea interno o externo a la organizacin. Hay que hacer los correspondientes estudios tcnicos, de mercado, financieros, de rentabilidad... as como una estimacin de los recursos necesarios y los costes generados. Todo ello constituye el elemento fundamental en el que se apoya el cliente (que puede ser la propia organizacin en el caso de proyectos internos) para decidir sobre la realizacin o no del proyecto. La segunda fase importante de planificacin tiene lugar una vez se ha decidido ejecutar el proyecto. Ahora es el momento de realizar una planificacin detallada punto por punto. Uno de los errores ms importantes y graves en gestin de proyectos es querer arrancar con excesiva premura la obra, sin haber prestado la atencin debida a una serie de tareas previas de preparacin, organizacin y planificacin que son imprescindibles para garantizar la calidad de la gestin y el xito posterior. Planificar es armonizar dos tipos de elementos muy diferentes entre s:

Al hilo de lo sealado al principio, la planificacin de los proyectos debe estar afectada de un notable grado de agilidad y dinamismo: no es razonable planificar un proyecto y pensar que esa planificacin es ya definitiva e inmutable. En casi todos los casos, la realidad no coincide exactamente con lo previsto, por lo que es necesario ir haciendo ajustes peridicos. La planificacin es una herramienta para la gestin y la toma de decisiones, no para imaginar en un primer momento una evolucin que posteriormente el tiempo se encargar de demostrar que estaba equivocada. Aunque existen tcnicas de planificacin muy avanzadas y elaboradas, la adecuada planificacin se basa, ante todo, en una actitud de anticipacin que no es sino una evidente manifestacin del sentido comn. Los procesos bsicos de planificacin se pueden resumir en el siguiente cuadro:

ETAPAS DE UN PROYECTO

Desde un punto de vista muy general puede considerarse que todo proyecto tiene tres grandes etapas1:

Fase de planificacin. Se trata de establecer cmo el equipo de trabajo deber satisfacer las restricciones de prestaciones, planificacin temporal y coste. Una planificacin detallada da consistencia al proyecto y evita sorpresas que nunca son bien recibidas. Fase de ejecucin. Representa el conjunto de tareas y actividades que suponen la realizacin propiamente dicha del proyecto, la ejecucin de la obra de que se trate. Responde, ante todo, a las caractersticas tcnicas especficas de cada tipo de proyecto y supone poner en juego y gestionar los recursos en la forma adecuada para desarrollar la obra en cuestin. Cada tipo de proyecto responde en este punto a su tecnologa propia, que es generalmente bien conocida por los tcnicos en la materia. Fase de entrega o puesta en marcha. Como ya se ha dicho, todo proyecto est destinado a finalizarse en un plazo predeterminado, culminando en la entrega de la obra al cliente o la puesta en marcha del sistema desarrollado, comprobando que funciona adecuadamente y responde a las especificaciones en su momento aprobadas. Esta fase es tambin muy importante no slo por representar la culminacin de la operacin sino por las dificultades que suele presentar en la prctica, alargndose excesivamente y provocando retrasos y costes imprevistos.

A estas tres grandes etapas es conveniente aadir otras dos que, si bien pueden incluirse en las ya mencionadas, es preferible nombrarlas de forma independiente ya que definen un conjunto de actividades que resultan bsicas para el desarrollo del proyecto:

Fase de iniciacin. Definicin de los objetivos del proyecto y de los recursos necesarios para su ejecucin. Las caractersticas del proyecto implican la necesidad de una fase o etapa previa destinada a la preparacin del mismo, fase que tienen una gran trascendencia para la buena marcha del proyecto y que deber ser especialmente cuidada. Una gran parte del xito o el fracaso del mismo se fragua principalmente en estas fases preparatorias que, junto con una buena etapa de planificacin, algunas personas tienden a menospreciar, deseosas por querer ver resultados excesivamente pronto. Fase de control. Monitorizacin del trabajo realizado analizando cmo el progreso difiere de lo planificado e iniciando las acciones correctivas que sean necesarias. Incluye tambin el liderazgo, proporcionando directrices a los recursos humanos, subordinados (incluso subcontratados) para que hagan su trabajo de forma efectiva y a tiempo.

Los periodos generales de duracin los podemos ver a continuacin:

Estas etapas citadas presentan, sin embargo, caractersticas bastante diferentes segn se trate de proyectos internos o de proyectos externos. Las principales diferencias aparecen en la etapa de planificacin. En el proyecto externo existen un conjunto de acciones que se relacionan con la necesidad de presentar una oferta al cliente y lograr la adjudicacin del contrato en competencia con otras empresas o personas. Si, por la razn que fuere, el contrato no se consigue el proyecto queda abortado antes de haberse comenzado y carece de sentido preocuparse de cmo debe ser gestionado. La exigencia comercial tiene, pues, un carcter prioritario para las empresas, siendo la consecucin del contrato paso imprescindible para poder acometer un proyecto concreto y, con una perspectiva ms amplia, condicin esencial para la supervivencia de la empresa. Puedes ver ms sobre la importancia del perfil comercial en el apartado de oferta. Haciendo referencia a las tres grandes etapas nombradas al principio, podemos ver la diferencia entre ambos tipos de proyectos:

Cuando se abordan proyectos grandes y complejos, la consecucin del resultado final depende de la realizacin armnica del conjunto de las etapas pertinentes con ayuda de los medios materiales y humanos requeridos en cada momento. La concepcin de las fases que han de ejecutarse, el orden de encadenamiento lgico de las mismas y la estimacin de la naturaleza y cantidad de recursos a emplear en cada momento, precisan de un conocimiento profundo de las tecnologas que concurren en el proyecto y de una experiencia que permita prever y superar las dificultades que en la prctica suelen aparecer. A continuacin se presentan las distintas etapas en el desarrollo de una aplicacin informtica1:
ETAPA 1 Nacimiento de la idea del proyecto El "cliente o promotor" expone sus necesidades y el deseo de resolver el problema por medios informticos. Se crea un primer documento breve que recoge el anteproyecto y es aprobado por la direccin o el comit correspondiente. ETAPA 2 Estudio de oportunidad El estudio de oportunidad concreta los objetivos y resultado a aportar por el proyecto, los plazos y costes previstos y los medios a emplear. ETAPA 3 Estudio detallado El jefe de proyecto define, ya en detalle, con el apoyo de los tcnicos de su equipo, el contenido del proyecto, su anlisis funcional,, las cargas de trabajo previstas y la metodologa a desarrollar. ETAPA 4 Cuaderno de cargas para informtica A partir del anlisis funcional se determinan en forma definitiva los volmenes, cargas de trabajo, calendario y medios a utilizar, dando lugar al contrato formal entre cliente, usuarios e informticos, frecuentemente conocido con el nombre de cuaderno de cargas o, ms concretamente, "pliego de especificaciones". ETAPA 5 Anlisis orgnico Los tcnicos realizan el anlisis orgnico y las especificaciones para programacin. ETAPA 6 Programacin y pruebas Se realiza la programacin de la aplicacin y las pruebas para programacin. ETAPA 7 Recepcin provisional Al resultar satisfactorias las pruebas se realiza la recepcin provisional, dando lugar a los manuales de usuario y de explotacin. ETAPA 8 Puesta en marcha La puesta en marcha de la aplicacin es una fase delicada que requiere una estricta vigilancia hasta comprobar su correcto funcionamiento. A continuacin se realiza un balance de los resultados del proyecto. ETAPA 9 Balance de funcionamiento Despus de varios meses de funcionamiento de la aplicacin se debe realizar un balance que permita apreciar los beneficios que realmente ha producido a la empresa. ETAPA 10 Auditora Transcurridos uno o dos aos, debe efectuarse una auditora de la aplicacin que permita comprobar si sigue siendo adecuada o si es necesario introducir modificaciones.

Desde el punto de vista de la metodologa de gestin de proyectos, tambin pueden identificarse varias fases que generalmente debern darse en todo tipo de proyectos: 1. 2. 3. 4. 5. 6. 7. Decisin de acometer el proyecto. Nombramiento del jefe de proyecto. Negociacin de objetivos. Preparacin. Ejecucin. Informacin. Control.

Dentro de la preparacin, se integraran actividades como la descripcin de actividades, identificacin de recursos, valoracin de los mismos -presupuesto-, planificacin y eventual reconsideracin de los objetivos.

LA OFERTA

El primer objetivo que aparece antes de acometer un proyecto es el de presentar una oferta con el fin de conseguir el contrato, es decir, convencer al cliente de que nuestra propuesta es ms adecuada que la de los competidores, ya sea en el aspecto tcnico, ya sea en las condiciones ofrecidas en cuanto a coste o plazo, sin olvidar la influencia que en la decisin del cliente suelen tener otros elementos menos objetivos, pero no por ello menos reales, como son la imagen de la empresa, las referencias anteriores, la confianza en las personas, etc. Dada la importancia de esta labor comercial y el hecho de que en muchos casos las personas con un perfil ms tcnico no suelen destacar por sus aptitudes comerciales, es muy frecuente que la organizacin de la empresa separe en rganos o personas diferentes la tarea de realizar y negociar la oferta de la labor de dirigir y ejecutar el proyecto. Y es aqu donde surge el primer conflicto, pues el comercial, en su fin de obtener el contrato, puede ofrecer una serie de condiciones y seguridades que posteriormente el tcnico considerar imposible de respetar. Este antagonismo entre las facetas tcnica y comercial de la oferta es algo que muy pocas empresas tienen totalmente superado. La dificultad radica precisamente en que la oferta tiene inevitablemente la doble caracterstica de documento tcnico y comercial. Tan negativo es realizar un oferta excepcional desde el punto de vista tcnico y no conseguir el contrato, como ofrecer "el oro y el moro" para hacerse con l y luego no poder respetarlo.

FINALIDAD COMERCIAL
Como hemos dicho, la oferta tiene ante todo una finalidad comercial. Ello implica la necesidad de respetar al menos los siguientes principios:

Captar bien el inters y la necesidad del cliente. Ofrecer lo que el cliente pide pero sin olvidar orientarle hacia lo que creemos que necesita o lo que sera conveniente ofrecerle. Hacer una oferta clara, atractiva para el cliente, bien concebida y presentada, completa. Dedicar el tiempo y el cuidado precisos para garantizar la calidad de la oferta. Sintonizar con el inters, la terminologa y la mentalidad del cliente. Destacar las ventajas de nuestra propuesta y los aspectos positivos que puedan interesar al cliente. Aportar todos los elementos que puedan enriquecer la oferta y dar confianza al cliente: fotografas, esquemas, referencias, ejemplos, muestras, etc.

ORIGEN TCNICO
Toda oferta supone en el caso de un proyecto imaginar el resultado final de la obra, los recursos que va a ser necesario emplear y, consecuentemente, la solucin tcnica que se va a desarrollar. El plazo de realizacin, presupuesto, calidades, etc. sern precisamente consecuencia de esa solucin tcnica concebida. Desde el punto de vista tcnico, tambin es aconsejable seguir una serie de normas o principios a la hora de elaborar la oferta:

Incluir una solucin tcnicamente correcta, viable y coherente con las necesidades del cliente. Concretar suficientemente las especificaciones tcnicas que habr de respetar la obra y que permitirn controlar su calidad. Aadir los planos o documentos necesarios para identificar claramente las caractersticas de la obra. Contemplar todos los datos importantes que el cliente precisa para poder tomar una decisin: calidades, plazos, costes, formas de pago, aportacin a efectuar por el propio cliente, servicio postventa, garantas. Identificar con claridad los compromisos que se adquieren mutuamente.

A menudo se argumenta que realizar una oferta tan clara puede resultar perjudicial para la faceta tcnica. Sin embargo, los clientes, cada vez ms exigentes en este aspecto, siempre agradecen y valoran muy positivamente una oferta tcnicamente bien hecha, donde quede claro a qu se comprometen ambas partes. Es verdad que hacer bien una oferta lleva tiempo y dinero, pero se debe entender como una inversin muy rentable, ya que lo que ahora se gaste ms tarde se ahorrar con creces en conflictos y en prdidas imprevistas.

LOS PROYECTOS INTERNOS

Lgicamente, en los proyectos internos no se presenta en la misma forma esta necesidad de realizar una oferta previa y redactar un contrato formal. S es conveniente analizar detenidamente el proyecto , con sus diversos grados de necesidad, con las diversas opciones tcnicas existentes, contemplando si se dispone de los recursos financieros y humanos precisos y eligiendo entre los diversos proyectos que se pudiesen acometer. Tambin resulta aconsejable en estos casos que la formulacin del proyecto, una vez adoptado las decisiones previas, se refleje en un documento que, pudiendo ser simple y breve, recoja con claridad los objetivos del proyecto. Ahora la faceta comercial queda relegada a un lado, y se busca un pseudocontrato que sirva como marco de referencia a la relacin entre organizacin y jefe de proyecto.

LOS OBJETIVOS DEL PROYECTO

Un principio bsico de en la gestin de proyectos, as como en toda actividad de gestin, es que los objetivos estn definidos a priori y con un grado de suficiente de claridad y precisin. Hay proyectos donde la definicin de objetivos se hace realmente difcil, pero esa dificultad no significa que no deba hacerse, puesto que cuanto ms inmaterial es o ms arriesgado sea un proyecto ms necesario ser contar con un marco de referencia, aunque sus contornos sean menos ntidos que en otras ocasiones.

OBJETIVO TRIPLE: Resultado, Coste, Plazo.

El objetivo del proyecto es siempre triple. No basta con conseguir uno o dos objetivos, ni hay que dar ms importancia a uno o a otro.

El primer objetivo es el resultado final de proyecto, es decir, la obra que se quiere realizar y que supone el origen y justificacin del proyecto, por lo que puede considerarse el objetivo ms importante y significativo. Pero la consecucin del objetivo tcnico no es suficiente. Eso s: ha de considerarse ms bien como una condicin ineludible. En el caso de abordar la electrificacin de una aldea, la aldea se debe electrificar, pero a cualquier precio ni en cualquier plazo. En el caso de proyectos externos, el objetivo de coste suele estar definido y tiene una importancia grande. Normalmente existe un contrato, y el proveedor deber respetarlo o tendr dificultades para revisar al alza el presupuesto. En proyectos internos es frecuente que el objetivo de coste no figure en forma explcita, algo que se debe intentar reducir. El plazo es el objetivo que ms fcilmente se deteriora, convirtindose as en el que mejor mide el grado de calidad de gestin del proyecto. A menudo se piensa que el plazo de realizacin de un proyecto no debe valorarse excesivamente, puesto que es algo que "casi nunca se respeta". Pero hay proyectos en los que este objetivo se convierte en el ms importante. Qu pasara si las obras del estadio olmpico no estuvieran terminadas para la inauguracin de los Juegos Olmpicos? El aspecto triangular de los objetivos se refuerza por la necesidad de coherencia y proporcin entre los mismos. Los tres son inseparables y forman un sistema en el que cada modificacin de cada una de las partes afecta a las restantes. Dado que la maximizacin individual de los tres criterios bsicos no es posible, es necesario maximizar una cierta combinacin entre ellos, priorizando aquellos que se adapten mejor a las estrategias de la empresa. La combinacin no es nica y, de hecho, puede pensarse en una zona de validez de la aproximacin seguida. La figura representa esa zona en la que el proyecto puede moverse dentro de la disponibilidad de recursos existente. Con ello, se quiere indicar tambin que no existe una nica forma posible de gestionar un proyecto satisfaciendo los requisitos bsicos. Un ahorro en costes (dentro de la zona permitida) permitira abordar otras actividades que mejoren, por ejemplo, la satisfaccin del cliente. Las tcnicas de gestin de proyectos deben considerar adems las actuaciones relacionadas con las desviaciones de la zona objetivo durante el desarrollo del proyecto y, por tanto, la aplicacin de medidas correctoras para evitar problemas adicionales. Ello implica ser capaces de monitorizar el cumplimiento de los objetivos identificados de forma continua (en la prctica en determinados hitos, o puntos de control del proyecto en los que hay que tener determinada visibilidad de resultados intermedios).

EL CUARTO OBJETIVO

Algunos autores introducen un cuarto elemento de gran inters: la satisfaccin del usuario. Con ello se quiere indicar la importancia de que el proyecto satisfaga las expectativas de ste. Un proyecto que cumpla las especificaciones, se realice en tiempo y dentro del presupuesto pero que no deje satisfecho al cliente no cumple sus objetivos. La satisfaccin del cliente suele considerarse ahora como una estrategia general de muchas empresas (sobre todo de las de servicios) y elemento clave para la valoracin del xito de los proyectos que emprendan.

CONTEXTO Y ESTRATEGIA
Un proyecto no puede concebirse al margen del resto de las actividades que lleva a cabo la organizacin. Todas las actividades contribuyen a conseguir unos fines generales expresados en las estrategias de la organizacin. Por ello, el tipo de organizacin influye no slo en los proyectos que se van a a realizar sino tambin en la forma en la que se realizan. Todo ello forma parte del contexto del proyecto. El conocimiento del contexto del proyecto es un elemento fundamental para asegurar el cumplimiento de sus objetivos. Como se ha dicho, la gestin del proyecto deber buscar el ptimo entre los objetivos. Para ello hay que conocer la importancia relativa de cada factor respecto a cmo responde a la estrategia de la organizacin ejecutora del proyecto. Distintos enfoques estratgicos, como poner productos lo antes posible en el mercado, o poner productos de calidad contrastada aunque no sean muy innovadores, o maximizar el beneficio, dan ms peso a un objetivo u otro. As mismo, el entorno externo puede forzar una determinada posicin ante la aparicin de una nueva tecnologa, los avances de la competencia, etc.

EL CICLO DE VIDA

Todo proyecto de ingeniera tiene unos fines ligados a la obtencin de un producto, proceso o servicio que es necesario generar a travs de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestin del proyecto. Al conjunto de las fases empleadas se le denomina ciclo de vida. Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologas empleadas. La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamao, con lo que rpidamente se hara inabordable si no fuera por la vieja tctica de divide y vencers. De esta forma la divisin de los proyectos en fases sucesivas es un primer paso para la reduccin de su complejidad, tratndose de escoger las partes de manera que sus relaciones entre s sean lo ms simples posibles. La definicin de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratacin de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad tambin se ve facilitado si la separacin entre fases se hace corresponder con puntos en los que sta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos). De la misma forma, la prctica acumulada en el diseo de modelos de ciclo de vida para situaciones muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que mejor de adapte a nuestros requerimientos.

ELEMENTOS DEL CICLO DE VIDA

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Segn el modelo de ciclo de vida, la sucesin de fases puede ampliarse con bucles de realimentacin, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar ms de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecucin aportaciones de los resultados intermedios que se van produciendo (realimentacin).

Para un adecuado control de la progresin de las fases de un proyecto se hace necesario especificar con suficiente precisin los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases. A continuacin presentamos los distintos elementos que integran un ciclo de vida:

Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas
(actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupacin temporal de tareas impone requisitos temporales correspondientes a la asignacin de recursos (humanos, financieros o materiales).

Cuanto ms grande y complejo sea un proyecto, mayor detalle se necesitar en la definicin de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un micro-proyecto en s mismo, compuesto por un conjunto de micro-fases.

Otro motivo para descomponer una fase en subfases menores puede ser el inters de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestin.

Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.

Esquema general de operacin de una fase

Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o
inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuacin o no a los requisitos funcionales y de condiciones de realizacin previamente establecidos. Cada una de estas evaluaciones puede servir, adems, para la toma de decisiones a lo largo del desarrollo del proyecto.

TIPOS DE MODELO DE CICLO DE VIDA

Las principales diferencias entre distintos modelos de ciclo de vida estn en:

o o o

El alcance del ciclo dependiendo de hasta dnde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricacin, y modificaciones posteriores hasta su retirada del mercado. Las caractersticas (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avin que un puente), o de la organizacin (inters de reflejar en la divisin en fases aspectos de la divisin interna o externa del trabajo). La estructura de la sucesin de las fases que puede ser lineal, con prototipado, o en espiral. Vemoslo con ms detalle:

Ciclo de vida lineal

Es el ms utilizado, siempre que es posible, precisamente por ser el ms sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fcil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase). Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no necesite resultados de las siguientes (realimentacin), aunque pueden admitirse ciertos supuestos de realimentacin correctiva. Desde el punto de vista de la gestin (para decisiones de planificacin), requiere tambin que se sepa bien de antemano lo que va a ocurrir en cada fase antes de empezarla.

Ejemplo de ciclo lineal para un proyecto de construccin

Ciclo de vida con prototipado

A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prev la utilizacin de tecnologas nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologas, impiden iniciar un proyecto lineal con especificaciones cerradas. Si no se conoce exactamente cmo desarrollar un determinado producto o cules son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). Este tipo de procedimiento es muy utilizado en desarrollo avanzado.
La experiencia del desarrollo del prototipo y su evaluacin deben permitir la definicin de las especificaciones ms completas y seguras para el producto definitivo. A diferencia del modelo lineal, puede decirse que el ciclo de vida con prototipado repite las fases de definicin, diseo y construccin dos veces: para el prototipo y para el producto real.

Ciclo de vida en espiral

El ciclo de vida en espiral puede considerarse como una generalizacin del anterior para los casos en que no basta con una sola evaluacin de un prototipo para asegurar la desaparicin de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede as considerarse como una sucesin de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente. A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en trminos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluacin de los resultados por el cliente no puede esperar a la entrega final y puede ser necesaria repetidas veces. El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificacin, diseo, realizacin y evaluacin (o conceptos y trminos anlogos).

En cada vuelta el producto gana en madurez (aproximacin al final deseado) hasta que en una vuelta la evaluacin lo apruebe y el bucle pueda abandonarse.

OBJETIVOS DE CADA FASE

Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan. Fase de definicin (qu hacer?)

o o o o o o o o o o
Fase de construccin

Estudio de viabilidad. Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto). Asegurar que los requisitos son alcanzables. Formalizar el acuerdo con los usuarios. Realizar una planificacin detallada. Identificar soluciones tecnolgicas para cada una de las funciones del sistema. Asignar recursos materiales para cada una de las funciones. Proponer (identificar y seleccionar) subcontratas. Establecer mtodos de validacin del diseo. Ajustar las especificaciones del producto. Generar el producto o servicio pretendido con el proyecto. Integrar los elementos subcontratados o adquiridos externamente.

Fase de diseo (cmo hacerlo? Soluciones en coste, tiempo y calidad)

o o o o o

Validar que el producto obtenido satisface los requisitos de diseo previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseo para corregir posibles lagunas, errores o inconsistencias. Fase de mantenimiento y operacin Operacin: asegurar que el uso del proyecto es el pretendido.

Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averas o desgastes habituales -este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averas o de desgaste):

LOS PROYECTOS DE I+D

En el caso de la investigacin bsica el resultado esperado son conocimientos cientficos. No existe ninguna fase de construccin y s fases que recojan las tareas de experimentacin. En la investigacin aplicada el resultado esperado suele ser alguna tecnologa aplicable para procesos o para productos. Dependiendo del grado de cercana a la aplicacin que llegue a alcanzarse el modelo puede ser bsicamente como el anterior o incluir una fase de aplicacin piloto. En el desarrollo de productos o procesos nuevos o significativamente modificados s aparece ya una fase de construccin, aunque normalmente se tratar de la realizacin de un prototipo. Normalmente el cliente no ser el usuario final, sino los departamentos de ingeniera de produccin de la propia empresa o de otra que contrata el desarrollo. La I+D es costosa por depender de personal muy cualificado, por realizarse de modo generalmente artesanal y por requerir bucles de realimentacin que multiplican, para hacer frente a incidencias, la duracin del proyecto.

CICLO DE VIDA EN INTERNET

Con Internet de por medio, todo se transforma en algo ms rpido. Internet ha conseguido en 5 o 6 aos lo que televisin o telfono han tardado dcadas. Tema: Autor: El ciclo de la vida en Internet Pilar Navas

El conocido ciclo de vida, basado en considerar que cualquier producto tiene una duracin limitada y que pasa por una serie de fases (nacimiento, crecimiento y maduracin) se ha acortado notablemente.
http://www.commercenetcatalunya.org/boletin56/not4.htm

IDENTIFICACIN DE ACTIVIDADES

Una de las primeras y ms importantes misiones del jefe de proyecto es la identificacin y descripcin de las actividades que es necesario acometer y desarrollar para llegar al resultado adecuado. Antes de iniciar la andadura hay que elegir el camino ms conveniente, el rumbo que se debe seguir y el ritmo a imprimir a cada etapa. Esta tarea implica elegir entre mltiples opciones y resolver un sinfn de incgnitas. Y todo ello hay que hacerlo "a priori", desconociendo lo que ocurrir en la realidad y asumiendo los niveles de complejidad e inhabitualidad que son propios de los proyectos. Se trata pues de un trabajo de naturaleza tcnica que slo podr ser realizado por un profesional en la materia, que rena la formacin tcnica necesaria y una suficiente dosis de experiencia. Por ello es necesario que el Jefe de Proyecto posea una elevada competencia profesional en la tecnologa dominante del proyecto, aparte de otras cualidades gerenciales y personales. No obstante, si la dificultad del proyecto lo requiere, el Jefe de Proyecto podr ser en este punto asesorado y aconsejado por otros expertos. En proyectos de gran envergadura puede ser necesario establecer un segundo escaln de jefatura dentro del proyecto, nombrando responsables de subproyectos o de paquetes de actividades o de actividades y tareas. La metodologa siempre es la misma: sibdividir el proyecto en partes con entidad propia pero ms dominables que el proyecto global. Si el caso lo justifica, la descripcin de actividades podr hacerse de forma piramidal en varios niveles: subproyectos, paquetes, actividades, tareas. Para la definicin de actividades es necesario contar con los siguientes datos:

La Estructura de Desagregacin de Proyecto Especificaciones y objetivos del proyecto Informacin histrica qu actividades fueron necesarias en proyectos similares anteriores Limitaciones presupuesto total, plazo de entrega... Hiptesis: se ha de elaborar una lista de actividades que complete la EDP incluyendo todas las actividades requeridas para realizar el proyecto.

En la tarea de descomposicin de actividades, se trata de subdividir los elementos del proyecto en componentes lo suficientemente pequeos para facilitar las tareas de programacin, ejecucin y control. Para ello, ser necesario:

Identificar los elementos principales del proyecto, fases y microfases. Identificar los componentes de dichos elementos Dnde acaba la descomposicin? Cuando se disponga de: entradas y salidas definidas obtencin de estimaciones adecuadas de duracin y coste Comprobar la correccin de la descomposicin son los componentes inferiores necesarios y suficientes? se puede programar y presupuestar cada componente?

Pero la enumeracin de actividades no es suficiente, y ha de ir acompaada de una descripcin concreta que permita comprender su razn de ser, su contenido, el resultado esperable, su responsable y las condiciones de ejecucin. Por ello, es recomendable disponer de alguna ficha o documento que sistematice dichas descripciones y sirva de qua a cuantos deban efectuarlas.

RELACIONES Es lgico que las distintas actividades de un proyecto no se realicen ni de forma sucesiva ni de forma simultnea. Se trata de enlazarlas en el orden ms conveniente posible para resolver adecuadamente los imperativos tcnicos del proyecto y para lograr la combinacin ptima de costes y plazos, obteniendo una lista de precedencias entre actividades. Sin embargo, no todas las actividades en un proyecto tienen que ser secuenciales. Las precedencias pueden ser de tres tipos: Tcnicas (p.ej. los cimientos antes que la estructura). Procedimentales: determinadas por la poltica y procedimientos de la organizacin (p.ej. el plan de calidad antes que el diseo detallado) Impuestas: por los recursos (p.ej. vacaciones del personal) por la administracin (p.ej el estudio de impacto ambiental antes que la ejecucin de la obra) por el contexto (climatologa, otros proyectos...).

En la labor de secuenciamiento de actividades y establecimiento de sus relaciones suele contarse con el apoyo de tcnicas de planificacin especficas que son comentadas en el apartado de programacin.

ESTIMACIN DE LA DURACIN DE LAS ACTIVIDADES Se trata de evaluar el nmero de perodos de trabajo estimados necesarios para completar la actividad. Datos para la estimacin de duraciones los recursos asignados a la actividad; la capacidad (productividad) de dichos recursos; informacin histrica proyectos anteriores similares bases de datos comerciales conocimientos y experiencia del equipo de proyecto

Tcnicas para la estimacin de duracin de actividades Asesora especializada, basada en experiencia en la gestin de proyectos en el sector. Estimacin por analoga, basada en informacin histrica de duraciones reales de actividades anteriores similares. Simulacin: Clculo de mltiples duraciones basadas en distintas hiptesis. Monte Carlo: definida una distribucin de probabilidad para cada actividad se calcula la distribucin de probabilidad para el proyecto completo.

LOS RECURSOS

La asignacin de los recursos suele ser, en la prctica, uno de los aspectos que ms complicaciones produce. La definicin y asignacin de recursos implica de hecho prever tres elementos: qu tipo de recursos se van a usar; en qu cantidad; durante cuanto tiempo.

Y los tres elementos estn estrechamente ligados, puesto que el coste de su aplicacin es el producto naturaleza del recurso x cantidad x tiempo, y, por lo tanto, para mantener el resultado fijo, cualquier variacin de una de las variables implica modificar alguna de las otras dos. La calidad de las estimaciones depende directamente de la capacidad y experiencia del jefe de proyecto y de la mayor o menor familiaridad en realizar ese tipo de proyectos. PLAZOS Y COSTES

Una vez que las tareas a realizar han sido identificadas y ordenadas en forma lgica y que se ha determinado qu recursos van a emplearse en cada una de ellas, aparecen con relativa facilidad los costes y plazos previsibles para el conjunto del proyecto. As, lo difcil es saber cuntas horas/hombre u horas/mquina y de qu tipo vamos a emplear. El coste de la unidad de recurso es en general fcil de conocer. Y el coste total de proyecto ser la suma del coste de todas las actividades. Algo similar ocurre con los plazos: si habamos calculado el plazo de realizacin de cada actividad en funcin de los recursos empleados y hemos establecido el encadenamiento lgico de la actividades, el plazo total del proyecto resultar del camino ms largo que definan las actividades y las relaciones establecidas 8el camino crtico en el grfico PERT). En el apartado programacin aparecen comentadas varias de las tcnicas que se utilizan para calcular estimaciones de plazos, as como el calendario del proyecto.

TCNICAS DE PROGRAMACIN

Las tcnicas de planificacin se ocupan de estructurar las tareas a realizar dentro del proyecto, definiendo la duracin y el orden de ejecucin de las mismas, mientras que las tcnicas de programacin tratan de ordenar las actividades de forma que se puedan identificar las relaciones temporales lgicas entre ellas, determinando el calendario o los instantes de tiempo en que debe realizarse cada una. La programacin debe ser coherente con los objetivos perseguidos y respetar las restricciones existentes (recursos, costes, cargas de trabajo, etc...). La programacin consiste por lo tanto en fijar, de modo aproximado, los instantes de inicio y terminacin de cada actividad. Algunas actividades pueden tener holgura y otras son las actividades crticas (fijas en el tiempo).

PASOS: Construir un diagrama de tiempos (instantes de comienzo y holgura de las actividades). Establecer los tiempos de cada actividad. Analizar los costes del proyecto y ajustar las holguras (proyecto de coste mnimo).

RESULTADOS: Disponer de un diagrama de tiempos. Conocer actividades crticas y determinar la necesidad de recursos.

Para comenzar la programacin, se ha de partir de los siguientes datos:

diagrama de red del proyecto (PDM, ADM...); estimacin de duracin de actividades; recursos asignados a las actividades; calendarios de recursos para actividades; limitaciones, como fechas fijas para resultados o fases del proyecto.

Segn los resultados que deseemos conocer, podemos hacer uso de unas determinadas herramientas o de otras. En el siguiente cuadro se muestran todas ellas, que pasamos a comentar a continuacin:

ESCALA TEMPORAL S - DEPENDENCIAS NO

Diagrama de Gantt
El diagrama de Gantt es un diagramas de barras desarrollados por Henry Gantt durante la I Guerra Mundial para la programacin del arsenal Frankford. En l se muestran las fechas de comienzo y finalizacin de las actividades y las duraciones estimadas, pero no aparecen dependencias. El grfico de Gantt es la forma habitual de presentar el plan de ejecucin de un proyecto, recogiendo en las filas la relacin de actividades a realizar y en las columnas la escala de tiempos que estamos manejando, mientras la duracin y situacin en el tiempo de cada actividad se representa mediante una lnea dibujada en el lugar correspondiente.

La utilidad de un grfico de este tipo es mayor cuando se aaden los recursos y su grado de disponibilidad en los momentos oportunos. Como ventajas tendramos la facilidad de construccin y comprensin, y el mantenimiento de la informacin global del proyecto. Y como desventajas, que no muestra relaciones entre tareas ni la dependencia que existe entre ellas, y que el concepto de % de realizacin es un concepto subjetivo.

Grfica de hitos
Un hito es un evento claramente verificable por otra persona y que requiere verificacin antes de poder proseguir con la ejecucin del proyecto. Por ejemplo, la obtencin y formalizacin de los requisitos de usuario constituye un hito en la realizacin de un proyecto de ingeniera software. La utilidad de los hitos se basa en la buena seleccin de los mismos. Pero al igual que los diagramas de GANTT, la programacin con hitos no aporta o refleja informacin acerca de la interdependencia entre tareas o actividades.

ESCALA TEMPORAL NO - DEPENDENCIAS S

Un diagrama de red es cualquiera de las representaciones que vinculan las actividades y los eventos de un proyecto entre s para reflejar las interdependencias entre las mismas. Una actividad o evento puede presentar interdependencias con actividades o eventos sucesores, predecesores, o en paralelo. Los ms importantes son:

PERT (Program Evaluation and Review Technique)

Desarrollado por la Special Projects Office de la Armada de EE.UU. a finales de los 50s para el programa de I+D que condujo a la construccin de los misiles balsticos Polaris. Est orientada a los sucesos o eventos, y se ha utilizado tpicamente en proyectos de I+D en los que el tiempo de duracin de las actividades es una incertidumbre. Dado que las estimaciones de duracin comportan incertidumbre se estudian las distribuciones de probabilidad de las duraciones. Con un diagrama PERT se obtiene un conocimiento preciso de la secuencia necesaria, o planificada para la ejecucin de cada actividad y utilizacin de diagramas de red. Se trata de un mtodo muy orientado al plazo de ejecucin, con poca consideracin hacia al coste. Se suponen tres duraciones para cada suceso, la optimista a, la pesimista b y la normal m; suponiendo una distribucin beta, la duracin ms probable: t = (a + 4m + b) / 6 . Generalmente se denominan tcnicas PERT al conjunto de modelos abstractos para la programacin y anlisis de proyectos de ingeniera. Estas tcnicas nos ayudan a programar un proyecto con el coste mnimo y la duracin ms adecuada. Estn especialmente difundidas el PERT y el CPM.

Aplicacin de las tcnicas PERT:

Determinar las actividades necesarias y cuando lo son. Buscar el plazo mnimo de ejecucin del proyecto. Buscar las ligaduras temporales entre actividades del proyecto. Identificar las actividades crticas, es decir, aquellas cuyo retraso en la ejecucin supone un retraso del proyecto completo. Identificar el camino crtico, que es aquel formado por la secuencia de actividades crticas del proyecto. Detectar y cuantificar las holguras de las actividades no crticas, es decir, el tiempo que pueden retrasarse (en su comienzo o finalizacin) sin que el proyecto se vea retrasado por ello. Si se est fuera de tiempo durante la ejecucin del proyecto, seala las actividades que hay que forzar. Nos da un proyecto de coste mnimo.

PDM (Precedence Diagramming Method)

Se basa en la utilizacin de una red en la que figuran las actividades en los nodos y los arcos representan demoras de tiempo entre los puntos (comienzo o fin de nodo) que unen, a la vez que muestran las dependencias. Permiten reflejar distintas relaciones de precedencia entre tareas. Entre las ventajas encontramos que el mtodo PDM tiene ms flexibilidad que el mtodo PERT ADM para la modelizacin de grandes proyectos, la representacin grfica es ms sencilla y no hay actividades virtuales. RELACIONES DE PRECEDENCIA Relacin FINAL-COMIENZO Relacin COMIENZO-FINAL Relacin FINAL-FINAL Relacin COMIENZO-COMIENZO

ADM (Arrow Diagramming Method)

Est orientada a las actividades, y se aplica en la industria de la construccin, en la que de forma habitual el tiempo de cada actividad es muy controlable. Las actividades se representan con flechas que se conectan con nodos para mostrar las dependencias.

Grfico PDM. Esta tcnica tambin se denomina actividad sobre nodo

Grfico ADM. Esta tcnica tambin se denomina actividad sobre flecha

ESCALA TEMPORAL S - DEPENDENCIAS S Diagrama de tiempos con interdependencias Se trata de un grfico de Gantt en el que aparecen las dependencias entre actividades y los recursos implicados en cada una de ellas. Permite de esta forma tener una idea ms real del proyecto que la que obtenamos con el diagrama de Gantt que mostrbamos anteriormente.

MTODO DEL CAMINO CRTICO CPM

Camino crtico El camino crtico en un proyecto es la sucesin de actividades que dan lugar al mximo tiempo acumulativo. Determina el tiempo ms corto que podemos tardar en hacer el proyecto si se dispone de todos los recursos necesarios. Es necesario conocer la duracin de las actividades. Este concepto es utilizado por dos mtodos:

Mtodo del tiempo estimado (CPM) La duracin de una actividad es la ms probable de duracin. Tiempo que se empleara en condiciones normales (m). Situacin determinista. Mtodo del tiempo esperado (PERT) Determinacin probabilstica de los tiempos esperados (Te), en funcin de los siguientes tiempos: o Duracin ms corta (a) o Duracin ms larga (b) o Duracin ms probable (m) (el mismo que en CPM) o Duracin esperada: Te = (a + 4m + b) / 6
Clculo del camino crtico

1. 2. 3. 4.
Holguras

Calcular Te m segn el mtodo empleado para cada actividad. Se coloca en el grafo encima o debajo de cada flecha. Calcular las fechas early -fecha mnima de comienzo de la actividad, MIC del suceso anterior- y last -fecha mnima de comienzo de la actividad, MAC del suceso posterior- de las distintas actividades que configuran el proyecto. (calcular el MIC y el MAC de todos los sucesos del proyecto). Clculo de las holguras. Identificacin del camino crtico.

La holgura de una actividad es el margen suplementario de tiempo que tenemos para determinar esa actividad. Las actividades crticas no tiene holgura.
Holgura de un suceso Hs: Holgura total de una actividad Ht: Holgura libre de unaHi: Holgura independiente Hi: Hs = MAC del suceso MIC del suceso Ht = MAC del s.p. MIC del s.a. duracin tarea HI = MIC del s.p. MIC del s.a. duracin tarea Hi = MIC del s.p. MAC del s.a. duracin tarea

Margen suplementario de tiempo de esa actividad sin que se altere el MIC de ninguna actividad crtica. Margen suplementario de tiempo para esa actividad sin que se altere el MIC de cualquier actividad. Margen suplementario de tiempo que existe en una actividad si las actividades precedentes terminaran lo ms tarde posible, y las actividades posteriores empezaran lo antes posible.

Actividades crticas
Una actividad es crtica cuando no se puede cambiar sus instantes de comienzo y finalizacin sin modificar la duracin total del proyecto. La concatenacin de actividades crticas es el camino crtico. En una actividad crtica la fecha early coincide con la ms tarda de comienzo, y la fecha ms temprana de finalizacin coincide con la fecha lastde la actividad. La holgura total es 0.

PROGRAMACIN CON RECURSOS LIMITADOS Y PROGRAMACIN CON COSTE MNIMO Programacin con recursos limitados
Hasta ahora slo se ha tenido en cuenta el anlisis de relaciones temporales entre las actividades del proyecto. Pero adems, hay que tener en cuenta los recursos, su consumo y sus limitaciones. El proceso, por lo tanto, ante la programacin sera el siguiente:

Programacin de duracin mnima sin tener en cuenta los recursos. Se estudia si moviendo las actividades no crticas dentro del margen que representan sus holguras, se puede conseguir el objetivo perseguido en relacin con los recursos. Si no es posible, aplicar alguna de las tcnicas para programar bajo limitacin de recursos.

Minimizacin de costes
Se trata de ajustar las holguras de las actividades, con la premisa de que la duracin total est prefijada por las actividades crticas. Hay costes que disminuyen con el tiempo (costes directos) y costes que aumentan con el tiempo (costes indirectos). Existen dos mtodos:

Hacer variaciones en el grafo: hacer actividades en paralelo, con lo que se reducen los costes. Variar los recursos asignados: los costes que representan las actividades son costes directos; si se consigue alargarlas, se reducen sus costes.
Proceso de minimizacin de costes Fase 1: Estimacin de los lmites de duracin y coste de cada actividad Fase 2: Determinacin de la pendiente de coste para cada actividad Fase 3: Alargamiento de todas las tareas no crticas que tengan pendiente de coste negativa Fase 4: Determinacin del intercambio de tiempo-coste ms favorable de las posibles en el camino crtico Fase 5: Tantear, alargando y acortando actividades crticas hasta que las pendientes positivas y negativas resultantes sean iguales

GESTIN DE RECURSOS HUMANOS

Cuando hablamos de Gestin de Recursos Humanos nos estamos refiriendo a la gestin de las personas que conforman la organizacin; y estamos, en este caso, hablando de la gestin del principal recurso del que disponen las organizaciones para mantener y mejorar su competitividad. Por qu esta importancia, cada vez mayor, al recurso humano? Nos encontramos en un ambiente en el que las tecnologas, los mercados, los productos... cambian muy rpidamente; en un ambiente en el que la innovacin y la actividad centrada en el cliente son dos de las principales armas estratgicas de que disponen las empresas. Y son las personas que conforman la organizacin las que van a innovar y las que van a conseguir que los clientes estn o no satisfechos. En el rea de la gestin de proyectos, la gestin de recursos humanos es un elemento fundamental. La creacin del equipo de trabajo es bsico para que el proyecto se pueda realizar bien. La figura ms importante la representa el Director de Proyecto, ya que su estilo de direccin y la forma de resolver los conflictos influye de manera decisiva en la marcha del proyecto. A l dedicamos un apartado especial. En esta seccin presentamos las siguientes divisiones:

El equipo de trabajo. Cmo se constituye, quienes lo integran, caractersticas... Perfiles tpicos de los integrantes. Director tcnico del proyecto, organizacin del equipo. Conflictos. Causas, cmo resolverlos.

EL EQUIPO DE TRABAJO
La constitucin del equipo de trabajo es la actividad ms delicada con la que se enfrenta un Director de Proyecto, y en la que ms debe demostrar sus capacidades. El equipo es creado "ad hoc" para una operacin determinada, y est compuesto en su mayor parte por personas sobre las que no tiene poder jerrquico, provenientes de diversos departamentos o especialidades, y que ha de funcionar como un todo armnico y ser capaz de conseguir los resultados esperados que, por definicin, son complejos, inusuales y arriesgados. Los propios empleados destacados a un proyecto pueden resistirse en ocasiones por miedo al cambio, por creer que en el proyecto van a tener que trabajar ms intensamente o por la incertidumbre sobre cul ser su puesto al reincorporarse a la unidad de origen. Ello exige un esfuerzo por parte de toda la organizacin, que requiere una mentalidad abierta y dinmica para aceptar el sentido de movilidad transitoria que caracteriza a los Proyectos. A continuacin resumimos los distintos mbitos desde los que se puede aportar personas al equipo de trabajo:

Asignacin permanente: esto sucede cuando hay un grupo de personas con unos conocimientos que les permiten realizar varios proyectos dentro del mismo tema. Generalmente, esta situacin tiene reflejo en la estructura organizativa de la compaa. Asignacin temporal: son personas que se incorporan de la misma unidad organizativa para la ejecucin de ese proyecto, pero que al finalizar ste continan a disposicin del Jefe de la Unidad (no necesariamente el Director del Proyecto). Reclutamiento de nuevas personas: esta situacin se produce cuando el proyecto requiere ms mano de obra de la disponible, o con conocimientos no disponibles. Hay que tener en cuenta que, en funcin de la duracin del proyecto, esta situacin puede ser inviable puesto que el tiempo requerido para seleccionar y contratar a una nueva persona puede ser muy alto.

Transferencia de personas de otros departamentos: situacin que se produce cuando hay personas disponibles en otras unidades de la organizacin. Estas personas suelen ser las que primero se le ofrecen al Director del Proyecto ante su peticin de personal, pero puede constituir una trampa al no ser las ms adecuadas. Lamentablemente, los responsables de departamento tienden a veces a considerar los empleados que trabajan bajo su mando (y que son recursos de la organizacin) como "sus" recursos, siendo remisos a desprenderse de determinada gente para aportarlos a un proyecto, cediendo a personal menos cualificado. Consultores: son siempre personas externas a la organizacin que poseen conocimientos muy especficos de los que no se dispone internamente. En muchos casos, estn ligados a las tecnologas que se van a utilizar en el proyecto. Subcontratadas: corresponden a las personas que van a ejecutar una determinada actividad que se subcontrata. No las elige el Director del Proyecto ya que pertenecen a la empresa subcontratista. Un caso particular de esta situacin es la de emplear personal ajeno a la empresa mediante una empresa de trabajo temporal que se asocia (como en el caso de la asignacin temporal) al equipo de trabajo, aunque la organizacin ejecutora del proyecto puede intervenir en el proceso de seleccin.

En muchas ocasiones la constitucin de un equipo de trabajo no se hace para un nico proyecto, sino para una lnea de actividad en la que a lo largo del tiempo se van a desarrollar diversos proyectos. Generalmente, la lnea de actividad responde a un tipo de productos o tecnologas en los que se van a aplicar conocimientos que el equipo de trabajo posee y que no puede limitarse al proyecto que se est desarrollando. Es necesario formar a los componentes del equipo de trabajo en las tcnicas necesarias para el proyecto, puesto que aunque la seleccin del equipo de trabajo intenta obtener personas con los conocimientos necesarios, nunca es posible cumplir totalmente este objetivo, debido a:

a. b. c.

Existencia de conocimientos ligados a los procesos o productos propietarios. Entrenamiento necesario en herramientas, tecnologas o mtodos no disponibles en las instituciones educativas y caractersticos de las empresas. Obsolescencia de los conocimientos tecnolgicos o de actividad de la empresa.

As pues, es importante tener en cuenta que los conocimientos que posea un equipo de trabajo deben renovarse continuamente, aunque no sea necesario aplicarlos inmediatamente en el proyecto. Esta estrategia ayuda a cohesionar ms al equipo dndoles un marco temporal de trabajo conjunto ms amplio.

INTEGRACIN Dentro de un equipo humano se requiere una relacin estable para la realizacin de las tareas del proyecto. Se presentan
distintos enfoques sobre la forma de proceder en este sentido:

o o o

Aislamiento: la relacin entre los componentes es mnima. Las tareas se descomponen en subunidades independientes y el control se basa en relaciones jerrquicas. Interdependencia: las relaciones se maximizan, mientras que las tareas se hacen muy dependientes. Cooperacin: realizacin de tareas conjuntas. Existe un apoyo mutuo entre subunidades.

La organizacin interna de un equipo de trabajo depende fuertemente de dos factores: 1. Tamao del equipo de trabajo - Grande. Se caracteriza por: * Los costes y esfuerzo para la comunicacin dentro del equipo de trabajo son altos, requirindose la existencia de mecanismos formalizados para ello. Se requieren inversiones tecnolgicas para promocionar el trabajo en equipo. * Se requiere un Director de Proyecto con ms experiencia. - Pequeo. Se caracteriza por: * Pueden requerirse generalistas. * Puede ser adecuado un Director de Proyecto con menos experiencia. 2. Duracin del proyecto - Corto. Se caracteriza por: * Contribuciones de persona a tiempo parcial. * Dificultades para justificar la recolocacin fsica del personal. * Mantenimiento del Director de Proyecto en todas las fases. - Largo. Se caracteriza por: * Contribuciones de persona a dedicacin plena. * El Director de Proyecto puede variar con las fases. * Posible recolocacin fsica del equipo de trabajo.

No se puede negar que el mayor valor de un grupo son las ideas, talentos y habilidades de los profesionales que lo conforman, y por lo tanto, la buena eleccin de los mismos, as como una correcta gestin en pos de aunar un conjunto de esfuerzos y conseguir unas metas comunes claramente identificadas, son la base del xito en cualquier proyecto.

SUBCONTRATACIN
Por ltimo vamos a hacer mencin de la subcontratacin, actividad que se lleva a cabo en muchos proyectos para realizar tanto tareas rutinarias de bajo nivel de cualificacin como tareas esenciales para las que no existe personal propio cualificado, como es el caso de los consultores. La pregunta sera: es posible controlar las competencias de las personas que van a participar en una subcontratacin ? La respuesta es afirmativa. Aunque es habitual que en el proceso de seleccin de una subcontrata se analice el equipo humano que va a realizar la actividad, es necesario que ese control se realice de forma contnua. Esta situacin es bsica en el caso de consultora o de proyectos de I+D en el que las decisiones se toman en funcin de la cualificacin y experiencia de las personas afectadas. En algunos sectores industriales, como el de automocin, las empresas fabricantes (ensambladores) de vehculos, prestan mucha atencin a las empresas auxiliares, manteniendo una estrecha relacin con ellas. Concretamente, apoyando sus procesos de formacin.

PERFILES DE UN EQUIPO DE TRABAJO

Un perfil es una caracterizacin genrica de un tipo de actividad ligado a las necesidades de una organizacin. No todos los perfiles son necesarios durante todo el proyecto ni en todos los proyectos. En funcin del ciclo de vida empleado y de las actividades a realizar, se pueden determinar a priori los perfiles requeridos. En la definicin de un perfil, intervienen los siguientes aspectos:

o o o o o o o

Conocimientos generales requeridos Conocimientos tcnicos especializados requeridos Habilidades de comunicacin requeridas Actitudes requeridas en el trabajo Relacin con otros perfiles Recursos materiales asociados al perfil Caractersticas temporales

A partir de esa informacin es posible conocer las personas requeridas y asignar responsabilidades individuales a cada una de ellas. No obstante, no debe confundirse esta definicin con las actitudes deseadas en una determinada persona. Recurdese que no siempre hay una relacin biunvoca. Extrapolando las caractersticas comunes de la mayor parte de proyectos, podemos establecer una relacin de perfiles tpicos, como la que se muestra a continuacin:

Documentalistas Diseadores Analistas Probadores Implementadores Vendedores Director de Proyecto Psiclogos Controladores de tiempos Administrativos

Es necesario hacer ciertos comentarios a alguna de las actividades expuestas. En primer lugar, todos los proyectos de ingeniera poseen la funcin de documentacin como una de las ms importantes. Tngase en cuenta que, en muchos casos, el proyecto slo genera documentacin durante las primeras fases del ciclo de vida. Esta funcin puede estar distribuida entre todos los componentes del equipo de trabajo y la responsabilidad de la misma recaer en los responsables de cada una de las fases y, en ltima instancia, en el Director de Proyecto. Desde luego, el contenido de la documentacin siempre la tiene que generar la persona o personas a cargo de una determinada tarea. Este enfoque tiene como consecuencia negativa la necesidad de integrar toda la documentacin generada por diversas personas en diferentes momentos de acuerdo con unos formatos preestablecidos y dificulta el control de la misma. Como contrapartida, es posible generar un perfil especfico como documentador con la responsabilidad, no de generar el contenido especfico de la documentacin que haya que generar, sino del almacenamiento, control, integracin, generacin de documentos concretos para diversos fines (e idiomas) y homogeneizacin de la misma.

Otro perfil importante y bsico de un equipo de trabajo en un proyecto de ingeniera es el de diseador. Existen distintos niveles a los que se desarrolla esta actividad (arquitecto, analista, funcional, a alto nivel, etc.) e incluso en proyectos grandes y complejos puede ser necesario distinguir un papel especial como Director Tcnico del Proyecto (no confundir esta figura con la de Director Tcnico de una organizacin que no tiene por qu estar ligada a un proyecto concreto sino a todas las actividades de carcter tcnico que se hagan en la empresa, como la gestin del recurso tecnolgico). El Director Tcnico tiene las siguientes funciones: 1. 2. 3. 4. Determinar las caractersticas tcnicas del producto o proceso objeto del proyecto. Tomar las decisiones relativas a las soluciones tcnicas a emplear. Determinar las tecnologas requeridas y responsabilizarse de su identificacin, evaluacin o seleccin en caso de no disponer de ellas. Responsabilizarse de la formacin tcnica del equipo de trabajo (en coordinacin con otras unidades funcionales de carcter horizontal de la empresa).

En proyectos pequeos esta figura se solapa con la de Director de Proyecto. Junto con ste ltimo y, en muchas ocasiones, el Director administrativo (costes, compras, personal, etc.), constituyen el equipo de direccin del proyecto.

ORGANIZACIN MATRICIAL DEL EQUIPO DE PROYECTO. RELACIN JEFE DE PROYECTO - JEFE UNIDAD FUNCIONAL
Como se ha comentado, una de las funciones ms relevantes de la direccin de proyectos es la de integrar en el equipo de proyecto a especialistas procedentes de otras reas o de otras empresas, responsabilidad que debe ser asumida por el jefe de proyecto. La mayor dificultad deriva de que se rompe uno de los principios de gestin clsicos, como es el principio de unidad de direccin. Es decir, un empleado de una unidad funcional que es asignado temporalmente a un proyecto pasa a tener dos jefes: su jefe jerrquico de la unidad funcional, del cual depende formal y habitualmente, y el jefe de proyecto, a las rdenes del cual trabaja slo en el mbito del proyecto. Ambos jefes deben colaborar en ciertos aspectos del proyecto, y en particular en el nombramiento de los diferentes tcnicos que intervendrn en el proyecto. Si el director funcional es el que posee los recursos y conoce la vala personal y forma de trabajar de los mismos, es evidente que ser la persona ms adecuada para proporcionar las personas que intervendrn en el proyecto. Pero si el jefe de proyecto ha de conseguir sus objetivos poniendo en juego los recursos aportados al proyecto, deber velar porque esos recursos sean idneos en calidad y cantidad, no pudiendo en caso contrario responsabilizarse de la consecucin de los objetivos. A continuacin representamos un diagrama con la organizacin matricial de un proyecto donde queda reflejada esta interdependencia entre los recursos asignados y las unidades funcionales.

CONFLICTOS

La existencia de conflictos no es evitable. La creacin de un equipo de trabajo siempre supone la existencia potencial de conflictos cuya resolucin es bsica para poder cumplir los objetivos del proyecto. Lo que es evitable es que lleguen a alterar fuertemente la marcha de un proyecto. La causa ltima de la existencia de conflictos es su aparicin en proyectos como entidades temporales que se desarrollan dentro de organizaciones ms estables en el tiempo. As, un proyecto es una fuente de competicin por el uso de recursos que la organizacin podra dedicar a otras actividades. Se pueden distinguir dos tipos de fuentes de conflictos:

o o

Endgenas. Surgen en el interior de un proyecto debido a problemas en su ejecucin o a los recursos disponibles. Exgenas. Surgen en la organizacin en su conjunto, afectando a los proyectos que se ejecutan en la misma.

Un Director de Proyecto slo puede atajar los conflictos endgenos y contribuir en mayor o menor medida a los exgenos en funcin de su responsabilidad en la organizacin, dependiendo de la estructura organizativa que sta posea.

CAUSAS
Las causas ms comunes, tanto partiendo del propio grupo de trabajo como provenientes del entorno de la organizacin, se pueden resumir en:

o o o o o o o

Calendarios Prioridades del Proyecto Estructura del equipo de trabajo Opiniones y compromisos tcnicos Procedimientos administrativos Costes Conflictos personales

RESOLUCIN
Durante un proyecto existen varias maneras de gestionar los conflictos. Dependiendo de la situacin y del problema, puede ser ms adecuado seguir una lnea u otra. Estilos de resolucin de conflictos1:

Confrontacin: Supone un enfoque racional de resolucin de problemas. Las partes que estn en disputa solucionan sus diferencias centrndose en los problemas , mirando a enfoques alternativos y eligiendo las mejores estrategias. La confrontacin puede contener elementos de otros modos., tales como compromiso o conciliacin. Compromiso: Regatear y buscar soluciones que aportan algn grado de satisfaccin a las partes involucradas en el conflicto. Puesto que el compromiso da resultados subptimos, el jefe de proyecto debe valorarlo en relacin a los objetivos del programa. Conciliacin: Destaca reas comunes de acuerdo y resta importancia a las reas de diferencia. Como la retirada, la conciliacin puede no responder a las cuestiones reales de desacuerdo. La conciliacin es un modo ms eficiente, sin embargo, puesto que al identificar reas de acuerdo puede ayudar a definir mejor las reas de desacuerdo, y adems el proyecto puede continuar en reas donde existe acuerdo de las partes. Imposicin: Imponer el punto de vista de uno a costa del otro. La fuerza se utiliza a veces como el ltimo recurso por los jefes de proyecto, puesto que puede provocar resentimiento y deterioro del clima laboral. Retirada: El Jefe de Proyecto no aborda los desacuerdos. Si la cuestin de desacuerdo es importante para la otra persona puede intensificar la situacin de conflicto. Este procedimiento se puede utilizar por el Jefe de Proyecto para permitir calmarse a la otra parte o para conseguir tiempo y poder estudiar la cuestin con ms profundidad.

Adems, la influencia directiva que ejerza el Director de Proyecto sobre el grupo hace que ste opte por un tipo de resolucin u otro. En la siguiente tabla se muestra esta correspondencia:

Rosenau, en su libro "Successful project management" (3 edicin, John Wiley & Sons, 1998) establece tres grandes vas para reducir los conflictos:

1. 2. 3.

Trabajar proactivamente en la reduccin de conflictos y no actuar como si no existiesen. Enfrentarse a ellos es la mejor manera de poder resolverlos. Tener y mantener una buena planificacin con estimaciones actualizadas y realistas acordadas por todas las personas implicadas. Establecer mecanismos de comunicacin fluida con todas las personas implicadas y con la direccin de la empresa.

UN CONSEJO: HAY QUE ENFRENTAR EL PROBLEMA

El primer paso para la solucin de un problema siempre es el detectarlo y aceptarlo como tal. La primera condicin es fcil de alcanzar; cualquiera puede percibir, salvo en contados casos, que algo anda mal en las relaciones del grupo, especialmente cuando se producen hechos de obvio antagonismo o agresiones verbales o fsicas. Aceptar que el problema es importante y que merece ser resuelto suele ser ms difcil, ya que no siempre las partes estn de acuerdo sobre la relevancia del conflicto: quien agrede o discrimina a otros se excusa a menudo minimizando sus actos, mientras que la vctima tiende naturalmente a exagerar la ofensa recibida. En esta primera etapa, entonces, deber explorarse profundamente la percepcin personal que cada parte tiene del problema, definindolo con total claridad hasta alcanzar el consenso adecuado respecto de su importancia. Es evidente que esto deber hacerse a travs de la conversacin, y por eso es vital que se pongan en juego las mejores aptitudes comunicacionales:

Respeto por los puntos de vista ajenos aunque no se coincida con ellos Tolerancia y ayuda para con los miembros del grupo que tengan dificultades al expresarse Paciencia y buena voluntad para escuchar a los otros

Ciertas actitudes personales son necesarias, adems de las anteriores:

Auto-control. No dejarse llevar por la ira ante opiniones que son adversas. Confianza. Presumir siempre la honestidad y la sinceridad en los otros. Honestidad. Decir siempre la verdad y ser sinceros al expresar opiniones. Humildad. Admitir desde el principio que jams podremos tener toda la razn.

El espritu de grupo debe prevalecer en esta etapa, y en general durante todo el proceso de resolucin de un conflicto. La clase debe sentirse cohesionada, si no en las opiniones o en los juicios de sus miembros, en la conviccin de que debe hallarse una solucin para beneficio de todos. Es necesario recordar siempre que el bien comn est por encima del bien individual; que el problema es de todos, no slo de las partes.

EL JEFE DE PROYECTO

El Jefe de Proyecto se destaca como la figura clave en la planificacin, ejecucin y control del proyecto y es el motor que ha de impulsar el avance del mismo mediante la toma de decisiones tendentes a la consecucin de los objetivos. El Jefe de Proyecto es un verdadero jefe, es decir, tiene poder ejecutivo y autoridad para mandar y tomar decisiones dentro del mbito y objetivos del proyecto. No es un mero coordinador o animador, como en algunas ocasiones se piensa. De la misma forma, tampoco sera correcto pensar que el Jefe de Proyecto tiene un poder absoluto y dictatorial sobre el mismo, ya que se encuentra inmerso en la estructura y organizacin de la empresa. Las relaciones bsicas del Director de Proyecto con otras unidades o personas dependen, en gran medida, de la estructura organizativa que posea la organizacin. A continuacin se muestra el caso de una empresa que sigue una estructura orientada a proyectos, donde se observa la importancia del Director de Proyecto.

Es necesario hacer mencin a una caracterstica importante como es el carcter transitorio de todo proyecto, lo que hace que la misin de un Jefe de Proyecto tenga la misma naturaleza temporal. Al trmino de un proyecto, el Jefe del mismo puede pasar a dirigir otro o a formar parte de su equipo, pero tambin puede pasar a desarrollar alguna actividad de tipo permanente dentro de la organizacin. Facilitar esa integracin a la estructura habitual debe ser una tarea no despreciada por la empresa, evitando as el "hacer pasillos" al que se ven sometidos muchos directores de proyecto entre una operacin y otra.

DE QU SE OCUPA
La misin del Director de Proyecto podra resumirse en: dirigir el equipo de que dispone para alcanzar los objetivos del proyecto. Ms concretamente, podemos destacar las siguientes funciones especficas:

Colaboracin con el cliente en la definicin y concrecin de los objetivos del proyecto. Planificacin del proyecto en todos sus aspectos, identificando las actividades a realizar, los recursos a poner en juego, los plazos y los costes previstos. Direccin y coordinacin de todos los recursos empleados en el proyecto. Mantenimiento permanente de las relaciones externas del proyecto: clientes, proveedores, subcontratistas, otras direcciones, etc. Toma de decisiones necesarias para conocer en todo momento la situacin en relacin con los objetivos establecidos. Adopcin de las medidas correctoras pertinentes para poner remedio a las desviaciones que se hubieran detectado. Responder ante clientes y superiores de la consecucin de los objetivos del proyecto. Proponer, en su caso, modificaciones a los lmites u objetivos bsicos del proyecto cuando concurran circunstancias que as lo aconsejen.

Esta definicin de funciones no puede considerarse exhaustiva. En cada entidad sera necesario hacer una definicin de funciones ms concreta y adaptada a las caractersticas particulares de cada proyecto.

EL PERFIL DE UN JEFE DE PROYECTO El Jefe de Proyecto debe tener una perspectiva mucho ms amplia que el conocimiento de las implicaciones tcnicas relativas al proyecto. Se trata de un gestor que necesita un triple perfil:

A.

Tcnico

El dominio de la tecnologa principal del proyecto es el punto de partida necesario para que el Jefe de Proyecto pueda comprender los puntos clave del mismo, planificar los recursos, generar ideas y soluciones eficaces, controlar la calidad, etc.

B.

Gestor

Pero el Jefe de Proyecto tambin debe poseer una notable aptitud gestora, pues no slo se encarga de una dimensin tcnica, sino que debe controlar y conseguir todos los objetivos del proyecto, incluyendo los financieros y de plazo, que suelen ser los ms crticos y ms frecuentemente incumplidos.

C.

Relaciones personales

El Jefe de Proyecto debe poseer una capacidad destacada para las relaciones personales, puesto por un lado, es el representante principal del proyecto ante clientes, proveedores, subcontratistas, otras direcciones funcionales, la propia empresa..., y por otro, debe dirigir a un conjunto de personas sobre los que normalmente no tiene poder jerrquico, y por lo tanto, es necesario hacerlo con grandes dosis de autoridad personal, tacto, habilidad y capacidad de conviccin.

ESTILO DIRECTIVOS
La habilidad de un Jefe de Proyecto para ganar el apoyo de otros depende de su manera de dirigir. Si bien el estilo de influencia se compone de una parte de autoridad personal y una poltica de recompensas o castigos, el Jefe de Proyecto no tiene capacidad directa de influir sobre las segundas (s podrn hacerlo indirectamente a travs de informes formales o informales) pues son competencia de los responsables funcionales. A continuacin se muestra una relacin donde se identifican nueve bases de influencia sobre el estilo directivo, datos1 recogidos durante una serie de seminarios sobre direccin de proyectos. Estn ordenados en orden de mayor a menor importancia para los propios directivos:

Conocimiento: Capacidad para ganar apoyo, debido a que el personal del proyecto posee una experiencia o conocimiento especiales; es decir, se considera que posee conocimientos que ellos estiman importantes. Autoridad: Capacidad para ganar apoyo, debido a que el personal del proyecto percibe que el jefe de proyecto tiene poder para dar rdenes.. Desafo del trabajo: Capacidad para ganar apoyo, basado en el disfrute personal mientras se realiza un tipo particular de trabajo; orientado a la motivacin intrnseca del personal.

Amistad: Capacidad para ganar apoyo, debido a que el personal del proyecto se siente atrado personalmente hacia el jefe de proyecto, al proyecto o ambos. Este poder de la amistad o poder referente y el de conocimiento, a diferencia del de autoridad, no es otorgado por la Direccin de la organizacin, sino que se gana a travs de su relacin con los integrantes del equipo. Asignacin de futuras tareas: Capacidad para ganar apoyo, debido a que el personal percibe que el jefe de proyecto es capaz de influir en la asignacin de sus tareas futuras. Distribucin de recursos: Capacidad para ganar apoyo, debido a que el personal percibe que el jefe de proyecto tiene el poder de asignar recursos financieros (presupuesto). Promocin: Capacidad para ganar apoyo, debido a que el personal del proyecto piensa que el jefe de proyecto puede otorgar recompensas organizativas. Salario: Capacidad para ganar apoyo, debido a que el personal del proyecto percibe al jefe de proyecto como capaz de dispensar directamente recompensas econmicas. Penalizacin: Capacidad para ganar apoyo, debido a que el personal siente que el jefe de proyecto puede aplicar penalizaciones que desean evitar. El poder basado en penalizacin est inexorablemente unido al poder basado en recompensa, siendo uno una condicin necesaria para el otro.

Existe una estrecha relacin entre el estilo de influencia y el estilo de resolucin de conflictos, encontrando que ciertos modos de influencia tienden a usarse junto con ciertos modos de resolucin de conflictos. De esta forma, resultados al respecto indican que los jefes de proyecto que ponen nfasis en sus conocimientos y en el reto del trabajo como bases de influencia, tienden a resolver los conflictos por confrontacin y a evitar la retirada, lo que parece lgico puesto que cuanto ms experto es un jefe de proyecto, ms capacidad tiene para evaluar y cuestionar el progreso y la calidad del trabajo. Por otro lado, aquellos jefes de proyecto que se basan en la amistad para obtener una mejor colaboracin con los subordinados, tienden ms a los modos de resolucin de conflictos de compromiso, conciliacin y retirada.

CMO ACTAN
Si se relaciona el estilo de influencia del jefe de proyecto, los modos que utiliza para resolver los conflictos y el nivel de resultado global del proyecto, se llega a cuatro conclusiones globales en relacin con las prcticas reales de direccin.

1.

Parece que los jefes de proyecto no adoptan un estilo de direccin que minimice la conflictividad global de sus proyectos. Las bases de influencia que los jefes de proyecto piensan que son ms importantes, como experiencia, autoridad y reto en el trabajo, no estn asociadas a menores grados de conflicto que las dems. Es decir, en proyectos complejos los conflictos son inevitables, y la buena realizacin de los trabajos depende a menudo del acierto con que el jefe de proyecto pueda resolver una cantidad de cuestiones conflictivas delicadas , sin poner en peligro el calendario acordado, el presupuesto o los parmetros acordados. La eficacia de los modos de resolucin de conflictos est determinada en gran medida por la situacin. A menudo, la conflictividad sobre diferentes cuestiones, como fechas, prioridades o recursos humanos, se origina debido a las interacciones del jefe de proyecto con diferentes elementos de la empresa. Por ello, gestionar diversas situaciones de conflicto requiere por su parte un alto grado de adaptabilidad a diferentes situaciones para encontrar el modo ms apropiado de resolucin de los conflictos. Los jefes de proyecto presentan generalmente mayor flexibilidad para alterar sus modos de resolucin de conflictos que para modificar sus estilos de influencia. Algunos modos de resolucin de conflictos pueden funcionar mejor que otros al aplicarlos sobre una cuestin dada, o sobre unos integrantes del grupo u otros. Sin embargo, alterar el estilo de direccin parece que les resulta ms difcil. Aunque un jefe de proyecto puede intentar tratar con sus diferentes interlocutores de forma diferente, lo ms probable es que en sus relaciones con una interfaz especfica utilice siempre el mismo estilo. El cambio continuo podra conducir a confusin y desconfianza por parte de sus interlocutores. Cuanto menos utilizan los jefes de proyecto las bases de influencia derivadas de la organizacin como autoridad, salario y penalizacin, y ms se basan en el reto del trabajo y en el conocimiento, reciben una valoracin ms alta de su habilidad para resolver de forma eficaz los conflictos y para dirigir proyectos. El reto del trabajo est ms relacionado con la integracin de los objetivos personales de los componentes del equipo en los objetivos del proyecto que otros modos de influencia, que parecen ms proclives a adaptarlos. El reto del trabajo est principalmente orientado hacia la motivacin intrnseca del personal, mientras que los otros mtodos estn ms dirigidos hacia las recompensas extrnsecas. Y no se puede olvidar que cuando se piensa que la autoridad es inmerecida, su uso puede aumentar la conflictividad.

2.

3.

4.

CMO MEJORAR LA EFICACIA DEL JEFE DE PROYECTO

A continuacin se muestra un conjunto de sugerencias que pueden incrementar potencialmente la eficacia del jefe de proyecto para resolver conflictos y, en ltimo lugar, para mejorar el resultado global del programa. La gestin eficaz de la comunicacin es uno de los principales factores que determinan la calidad del entorno organizativo. Al tener que crear el jefe de proyecto equipos a varios niveles de la empresa, es importante que las decisiones clave del proyecto, como los objetivos o las tareas de cada uno, sean comunicadas de forma apropiada a todo el personal relacionado con el proyecto. Las reuniones de revisin pueden ser un buen medio. El jefe de proyecto debe buscar un estilo de liderazgo que le permita adaptarse a las enfrentadas demandas de clientes, miembros del equipo y organizacin, sin tener miedo de variarlo si es preciso para estar en consonancia con lo que se exige en cada momento. Siempre, deben mantener y desarrollar sus conocimientos tcnicos en el campo de trabajo, ya que sin entender la tecnologa que estn manejando no se ganarn la confianza de los miembros del equipo , ni crearn credibilidad en los clientes.

Sus propias acciones influyen decisivamente en el clima de trabajo del equipo. Su preocupacin por los miembros del equipo, su habilidad de integrar los objetivos y necesidades personales de los componentes con los objetivos de ste y su capacidad para crear entusiasmo por el trabajo estimulan un ambiente de gran motivacin, involucracin en el trabajo, comunicacin abierta y un mejor resultado final del proyecto. Los jefes de proyecto deberan tratar de acomodar los intereses y deseos profesionales de los integrantes del proyecto, cuando se les asigna sus tareas. El resultado del mismo tambin depende de lo bien que se les proporcionen trabajos desafiantes para motivarles y de lo bien que se encajen sus objetivos personales en los del proyecto..

En cuanto a su habilidad para manejar los conflictos, deben conocer las principales causas que los determinan en su entorno y los momentos ms probables en que ocurren en la vida de los proyectos, deben considerar la efectividad de los modos de resolucin de conflictos que han utilizado en el pasado y experimentar con modos alternativos si sienten que se precisa una actuacin mejor. Resumiendo, podramos decir que:

LA MOTIVACIN INTRNSECA DEL PERSONAL DEL PROYECTO ...

- Conocimientos

- nfasis en la penalizacin y...

- Capacidad de establecer lazos de amistad

- ... en la autoridad

- Reto del trabajo

- Poca habilidad en conflictos

LA POSICIN DE PODER DEL JEFE DE PROYECTO ... ... depende de:

Lugar que ocupa en la empresa El alcance y naturaleza del proyecto Autoridad que se haya ganado Capacidad de influir en la promocin y futuros trabajos de los participantes

Martes, 20 de mayo del 2008

Gestin del Conocimiento

Para comentar, exponer o explicar sobre Gestin de Proyectos estan invitados en el siguiente grupo. .
http://groups.google.com/group/pmo1

Si tiene alguna pregunta?, no dude en hacerla aqui, con gusto la contestare.

PREGUNTAS? . Publicado por Diego Arteaga en PMO a las 19:39

Martes, 1 de abril del 2008

Cultura vrs Herramientas: ambas claves para lograr Mejores Proyectos

En la bsqueda continua de nuevas formulas para mejorar los resultados en los proyectos las organizaciones se encuentran frente a la toma de decisiones como de adquisicin de un software, o porque no?, modernizar el existente; con la premisa de que esta vez si atinaran en el objetivo. . Sobre esto, le un articulo enviado en la lista de proyectos de ASIC el pasado 1 de abril donde se menciona la importancia de una herramienta de software, su proceso de implementacin y el estado de madurez de la organizacin para que el proceso no sea tan traumatico, y estos son mis comentarios: . ...Me sumo al esfuerzo de Manuel por dar a conocer herramientas de software que le ayuden al Gerente de Proyecto en su no muy fcil responsabilidad de planear, seguir y controlar actividades en un proyecto. Igualmente, coincido con sus anotaciones que el tema de gestin no para en una herramienta, esta es una base firme para lograrlo, pero en la practica, si no hay Patrocinadores, Directivos, PMO's que estn haciendo seguimiento a esta gestin, la Gerencia del Proyecto se diluye en actividades propias de realizacin del producto o en otras que distraen la atencin del seguimiento y control al proyecto.

Es por eso que las PMO han iniciado su establecimiento en organizaciones Colombianas, para propiciar esos escenarios, acogiendo las mejores practicas y finalmente contribuir con buenos resultados en nuestros proyectos.

Las PMO o sus gestores, deben simplificar la puesta en prctica de una solucin informtica que les ayude a los Gerentes y a las propias PMOs. Menciona el autor: "Tenemos que ser claros sobre el problema que estamos intentando solucionar, y honestos sobre nuestras capacidades y limitaciones actuales. Lo ms importante, tenemos que reconocer nuestra madurez como organizacin, y el grado en la cual nosotros manejamos el hoy". . No es el software mas sofisticado y moderno lo importante, lo verdaderamente importante es el camino que utilicemos para implementarlo y llevarlo a feliz termino. . Para ello: Debemos ser gestores de cambio! . Nota: No confundir el proceso anterior con obtener "certificaciones" las competencias no se enmarcan en un papel. Publicado por Diego Arteaga en Tecnologia a las 12:45 | Comentarios (0) | Referencias (0)

Jueves, 21 de febrero del 2008

Sitios de interes PMO

1. Oficina de Gerencia de Proyectos: Teora y prctica 2. Caso: Diagnstico implementacin de una Oficina de Proyectos 3. Mejores Proyectos: "qu hago con esto el lunes en la maana" Publicado por Diego Arteaga en PMO a las 20:21

Mircoles, 16 de enero del 2008

Blogs de interes en Gestin de Proyectos

Actualice el listado que tengo de referencia como blog con la tematica de Gestin de Proyectos Alejandro Barros: Oficina de Proyectos (PMO) El Caf de Joe: Para Gerentes de Proyectos SEIS: Espacio sobre Gestin de Proyectos Legnita Press: de Angel Agueda... Direccion de Proyectos. Pablo Fernando Sanchez...Tecnologia y Proyectos DEJAMESER

Podes ayudarme en busqueda de ms. Publicado por Diego Arteaga en PMO a las 18:48 | Comentarios (2) | Referencias (0)

Mircoles, 5 de diciembre del 2007

Qu se hace en una Oficina de Gestin de Proyectos (PMO)

En el Post de DEJAMESER nos invita a reflexionar acerca de lo que realmente hace o puede hacer una PMO en una organizacin.

. Existen dos tipos de organizaciones, las que trabajan por procesos y las que trabajan por proyectos. . En la primera es comn NO encontrar una PMO, claro esta, solo hasta cuando el numero de proyectos a desarrollar se le sale de las manos a la alta Gerencia, es cuando inician a formarla, pero para ello tienen que empezar a recoger funciones que haban repartido a varias reas, entre ellas la Financiera, Recurso Humano, Operaciones y Subgerencias. . En la segunda el tema es claro, hay que administrar el trabajo por proyectos y la alta gerencia en si conforma en su siguiente nivel una PMO. . Pero esta claro, ambas pueden necesitar una PMO!, ahora por dnde comienzo?, dnde la ubico?, se encargar a no de la ejecucin de los proyectos? o solo le corresponder el seguimiento?, estas respuestas son propias de cada organizacin y de su modelo de gobierno (estrategia, personas y procesos) . De otra parte en el alcance de la PMO hay que preguntarse que la Justifica y que Beneficios quiero con ella?, las respuestas van orientando los Servicios que finalmente se quiere que la PMO ofrezca en la organizacin. . Entremos en materia, veamos lecciones aprendidas en las empresas donde hoy funciona una PMO...Continuar. Publicado por Diego Arteaga en PMO a las 19:55 | Comentarios (0) | Referencias (0)

Martes, 4 de diciembre del 2007

Software Libre para la Gestin de Proyectos

Consideren esta lista como una posibilidad de herramientas tecnolgicas para ayudar en la gestin de los proyectos, recuerden que ellas no gestionan los proyectos, esa labor esta designada exclusivamente para los Gerente de Proyecto (Project Manager), muchos se equivocan (o dir se disculpan...) diciendo que no han gestionan bien los proyectos asignados, porque no tienen una herramienta tecnolgica de gestin de proyectos.

OpenProj GanttProject Open Workbench Clockingit B-kin Project Monitor Dotproject

Publicado por Diego Arteaga en Tecnologia a las 18:46

Lunes, 19 de noviembre del 2007

Herramientas para una PMO

Algunas herramientas que podemos utilizar para gestionar la cartera de proyectos son: Rational Portfolio Manager de IBM

Portfolio Project de MS - (EPM) Clarity, Project & Portfolio Management (PPM)

Publicado por Diego Arteaga en Tecnologia a las 18:20

Viernes, 5 de octubre del 2007

Metodologia de Gestin de Proyectos en la red

Una metodologia interesante sobre Gestin de Proyectos publicada en Internet:

Gestin de Proyectos: GETEC - Universidad Politecnica de Madrid

Publicado por Diego Arteaga en Gestin de Proyectos a las 16:57

Viernes, 21 de septiembre del 2007

Los 10 errores principales del nuevo Director de la Oficina de Proyectos

Les comparto la traduccin realizada por SEIS de este post original de Project. "...Los 10 errores principales del nuevo Director de la Oficina de Proyectos son los siguientes: 10. Vender su casa para estar ms cerca del nuevo trabajo. 9. Comprar acciones de su nueva empresa para demostrar compromiso. 8. No entender que OGP significa Opuestos desde la Gerencia de Proyectos. Aqu no se me ocurre una traduccin mejor, en ingls sustituye PMO (Project Management Office) por Project Manager are Opossed, es decir en vez de Oficina de Gestin de Proyectos, los Jefes de Proyecto se Oponen. 7. Creer lo comentado durante la entrevista de trabajo sobre responsabilidad en la gestin de proyectos. 6. Creer lo comentado durante la entrevista de trabajo sobre las habilidades necesarias para formar parte de la Oficina de Proyectos. 5. Pensar no puede ser muy duro ayudar a la organizacin en algo que le interesa tanto. 4. Pensar no puede ser muy duro ayudar a los Jefes de Proyecto en algo que les interesa tanto. 3. Pretender que una organizacin externa desarrolle los nuevos procedimientos. 2. Decidir que lo que realmente se necesita es la mejor formacin posible en gestin de proyectos y finalmente, el error fatal 1. Aceptar el trabajo

Si has trabajado o trabajas en una Oficina de Proyectos, te tiene que hacer gracia. Sino .. tenlo en cuenta por lo que pueda pasar..." je,je,je, es realmente bueno,... gracias SEIS. Publicado por Diego Arteaga en PMO a las 17:40

Sbado, 25 de agosto del 2007

Niveles de Maduracin - OPM3

En la medida en que una organizacin logra sus objetivos de negocio y organizacionales va subiendo el nivel de madurez de la organizacin. La misin de una organizacin se traduce en los objetivos que alternadamente consiguen, traducidos a estrategias tcticas y resultados. Las iniciativas mltiples se manejan a travs una cartera de proyectos (agrupacin de programas y/o de

proyectos) para facilitar una mejor gestin del trabajo que resuelva los objetivos estratgicos. OPM (Organizational Project Management) es el uso del conocimiento, de las habilidades, de las herramientas y de las tcnicas en las actividades de organizacin y del proyecto para alcanzar objetivos de una organizacin proyectizada. El estndar OPM3 de PMI proporciona un marco por el cual su organizacin puede examinar el alcance de los objetivos estratgicos a travs de las mejores prcticas en la administracin de proyectos organizativos. OPM es la administracin sistemtica de proyectos, de programas y de iniciativas que deben alinearse para el logro de metas estratgicas. El modelo de la madurez OPM3 ilustra el grado en el que una organizacin practica a administracin de proyectos organizativos. Existen 5 pasos:

- Nivel 1: Lenguaje Comn, - Nivel 2: Procesos Comunes, - Nivel 3: Metodologa Singular, - Nivel 4: Benchmarking, - Nivel 5: Madurez. Publicado por Diego Arteaga a las 18:25

Viernes, 10 de agosto del 2007

Firmas Consultoras en Gestin de Proyectos

Algunas instituciones que en Colombia han aportado con un grano de arena en materia de Gestin de Proyectos son: . Publicado por Diego Arteaga a las 18:51 PMI, Capitulo Bogota U-MYND GOMEZ PROJECT AND TRAINING ESCUELA COLOMBIANA DE INGENIERIA UNIVERSIDAD JAVERIANA QUALITY MANAGEMENT SISTEMAS EXPERTOS ACIS

Martes, 17 de julio del 2007

Un buen Equipo para el Proyecto

Conformar un buen equipo para el proyecto no es tarea fcil, - de hecho ninguna tarea en proyectos es fcil o difcil, depende en si misma del alcance del proyecto y de la cultura de la organizacin donde se desarrolla. . Existen artefactos que nos ayudan a identificar y mostrar un equipo de proyecto: Project Chart, Organigrama, EDT (WBS), Plan de RRHH; Pero un buen equipo no se consigue diligenciando plantillas, lneas de mando, o colores en presentaciones de power point, para ello se requiere de un anlisis mas profundo de las competencias de las personas disponibles internas y externas, y un detallado anlisis de las tareas y los roles que se requieren para conseguir los objetivos del proyecto. . Para elegir el equipo adecuado para el proyecto hay muchos tips: .

1. Elija primero un gerente calificado para que gestione con conocimientos, habilidades y tcnicas el proyecto; No es indispensable que sea el mejor en el conocimiento del producto. . 2. Genere una lista de roles que requiere en el proyecto, esta lista la puede iniciar desde la misma construccin del Project Chart, y que en alguna medida tenga adelantado una EDT de segundo nivel. . 3. Genere una lista de personas que dentro de la organizacin podran suplir los roles requeridos. Se aconseja evaluar la disponibilidad del personal a solicitar antes de establecer compromisos. . 4. Evalu competencias personal vrs roles . 5. Genere una lista de personas (empresas) externas que le puedan contribuir con algunas o la totalidad de las tareas / paquetes de trabajo necesarios para lograr el alcance del proyecto. . 6. Evalu competencias. . 7. Pinte el equipo del proyecto (organigrama funcional o jerrquico) . 8. Si aun necesita mejorar, busque personal que pueda negociar en otros proyectos, reas, o empresas, y negocie el pase. . 9. Califique las diferentes alternativas por rol, el gerente del proyecto debe estar de acuerdo con todas las personas elegidas. Las personas deben estar de acuerdo en participar en el proyecto. . 10. Decida y comunique el equipo de proyecto a todos los interesados (skateholders). . Aqu los invito a leer el articulo "seis consejos para armar un buen equipo para el proyecto" tomado de la IAAP Publicado por Diego Arteaga en Gestin de los Recursos Humanos a las 17:20

Domingo, 24 de junio del 2007

Servicios de una PMO

Capacitacin, Entrenamiento, Coaching Documentacin de proyectos Coordinacin de los proyectos Manejo de los recursos Control sobre indicadores de costo, tiempo y calidad en el proyecto Programacin de proyectos

Visibilidad de proyectos Evaluacin asistida del retorno de la inversin Ayuda en la creacin de una visin efectiva de los informes Asistencia en la creacin de un plan de proyectos Ayuda a la coordinacin de los recursos para mltiples proyectos Ayuda con un listado para la adquisicin de recursos Inspeccin del progreso del proyecto y su metodologa Soporte administrativo

Publicado por Diego Arteaga en PMO a las 17:31

Martes, 19 de junio del 2007

Beneficios de una PMO

Estandariza la metodologia, los procedimientos, herramientas y plantillas para la gestin. Prioriza las estrategias, programas y proyectos. Mejora la estimacin y el cumplimiento de los tiempos en el proyecto. Mejora el presupuesto y el cumplimiento de la ejecucin de los costos asignados al proyecto. Mejora los niveles de calidad en el proyecto y en el producto Visibilidad de los proyectos. Confiabilidad en la informacin para la toma de decisiones dentro del proyecto o de la alta gerencia. Optimiza los niveles de comunicacin entre proyectos. Racionaliza el uso de recursos compartidos. Propicia la adecuada administracin de la configuracin de los proyectos y el despliegue de las lecciones aprendidas. Minimiza los riesgos y su impacto.

.
Publicado por Diego Arteaga en PMO a las 15:16

Mircoles, 13 de junio del 2007

Definicin de una PMO

Una oficina de gestin de proyectos (PMO) es una unidad de la organizacin para centralizar y coordinar la direccin de proyectos a su cargo. . Una PMO tambin puede denominarse oficina de gestin de programas, oficina del proyecto u oficina del programa. . Una PMO supervisa la direccin de proyectos, programas o una combinacin de ambos. . La PMO pone el nfasis en la planificacin coordinada, la priorizacin y la ejecucin de proyectos y subproyectos vinculados con los objetivos de negocio. . Las PMO pueden operar con continuidad en aspectos que van desde proporcionar las funciones de respaldo para la direccin de proyectos bajo la forma de formacin, software, polticas estandarizadas y procedimientos, hasta la direccin y responsabilidad directas en s mismas para lograr los objetivos del proyecto.

. Se puede delegar a una PMO especfica la autoridad para actuar como interesada integral y estar encargada de tomar decisiones clave durante la etapa de iniciacin de cada proyecto . Tambin puede estar autorizada para hacer recomendaciones o concluir proyectos a fin de ser congruente con sus objetivos de negocio. . Adems, la PMO puede participar en la seleccin, direccin y reubicacin, si fuera necesario, del personal compartido de los proyectos y, si es posible, del personal dedicado de los proyectos.