Proyecto y administración de proyectos · PDF fileProyecto y administración de proyectos Antes de involucrarnos en el apasionante tema de la administración de proyectos, es necesario

Proyecto y administración de proyectos

Antes de involucrarnos en el apasionante tema de la administración de proyectos, es necesario conocer de manera clara el significado de las palabras que le componen.

A manera de introducción a continuación les presentamos las definiciones de administración y proyecto, para luego entonces, enumerar las características y áreas que componen la administración de proyectos.

Qué es la administración:

Es el proceso de planear, organizar, dirigir y controlar, las actividades y el uso de los recursos con el fin de lograr uno o más objetivos.

Qué es un proyecto:

Es un trabajo o esfuerzo que se ejecuta una sola vez y que persigue un fin específico, y tiene como característica principal producir resultados únicos como un producto o un servicio.

Para alcanzar el fin establecido, es necesario definir objetivos o metas (qué hacer) y actividades o procesos (cómo hacer) que deberán cumplirse en un tiempo asignado, considerando para ello el inicio y termino del mismo.

Necesario es entonces también, la asignación y organización de todos los recursos involucrados para su ejecución.

Para su ejecución y éxito, el proyecto debe seguir una serie de pasos realizados por roles involucrados, para ir cumpliendo objetivos y/o desarrollando/utilizando productos y recursos.

En consecuencia podemos decir que los principales parámetros de un proyecto son:

Alcance Recursos (costo del esfuerzo principalmente) Tiempo

Dichos parámetros reúnen las 2 características siguientes:

1. Cada parámetro es función de los otros 2 2. Mover un parámetro implica cambios a los otros (por lo menos a 1)

En conclusión podemos decir que un proyecto es la ejecución en un momento determinado de un proceso o actividades con un tiempo, un costo y un alcance definido y es el principal objetivo del líder de proyecto el planearlos y controlarlos.

Perfil del Líder de Proyecto

El líder de proyecto, o administrador de proyectos, es responsable de administrar proyectos desde que inicia hasta que se completa.

Entre sus responsabilidades se incluye:

el desarrollo del plan del proyecto, la identificación de los requerimientos y el alcance del proyecto, la comunicación, la administración de los recursos humanos y materiales, el control de tiempos, identificación y control de riesgos, administración de los costos/presupuesto, el aseguramiento de la calidad, el reporte y evaluación del desempeño del proyecto.

El líder de proyecto debe mantener su foco en asegurar que el proyecto se termine en el tiempo y presupuesto planeado, y muy frecuentemente con tiempos limitados.

Algunas de las cualidades que uno debe tener para convertirse en un buen líder de proyecto son las siguientes:

Organizado y metódico Facilidad para relacionarse con gente Buena comunicación oral y escrita Liderazgo Conocimientos técnicos básicos

El Triángulo de Administración de Proyectos

El concepto básico que todo administrador de proyectos debe de manejar es el referente al triángulo de administración de proyectos. Se trata de tener muy claro desde un principio cuál es el alcance del proyecto, el tiempo requerido y los recursos/presupuesto necesario para completarlo. Son los tres parámetros básicos con los que tendrá que lidiar el administrador de proyectos y que, al final, determinarán en gran medida si el proyecto fue o no exitoso.

En un principio hay que identificar cuál es el alcance del proyecto, es decir cuáles son los requerimientos a satisfacer en el proyecto. Con base en esta información podemos determinar cuántos recursos (gente, herramientas, presupuesto) necesitamos para poder desarrollarlo. Pero, esto dependerá del tiempo en el que se requiera completar el proyecto. Si tenemos disponibilidad de recursos, entonces podremos reducir el tiempo. Si no hay presión de tiempo entonces podremos disponer de menos personal y recursos para poderlo completar.

Si se nos da flexibilidad en cuanto al alcance a cubrir, entonces podremos reducir tiempos y/o recursos para el proyecto.

Nuestro cliente en el proyecto nos puede restringir dos de los tres parámetros, pero nunca los tres. Cuando inicies un proyecto dale a escoger 2 de 3: alcance, tiempo o costo. Si pretende imponerte los 3 la probabilidad de tener un proyecto exitoso será cercana a cero.

Determinar los tiempos y costos es una tarea de por sí complicada. Y si decides aceptar una fecha límite con recursos limitados con un objetivo o alcance no negociable, entonces estás en serios problemas.

Y si se da el caso de que tú y tu equipo sobrevivan al proyecto y lo terminen bajo estas condiciones, muy probablemente el nivel de calidad del producto terminado dejará mucho que desear. Comenzar un proyecto con un plan de trabajo irreal es la mejor fórmula para fracasar en la administración de tu proyecto.

Claro que también existe la posibilidad de dar atole con el dedo diciendo que sí a todo lo que pide el usuario (incluyendo tiempos y costos). Y al final del proyecto no le importe cómo se terminó. Aunque corres el riesgo de ser señalado como el culpable principal del fracaso del proyecto con las consecuencias correspondientes.

Guía Básica para Administrar un Proyecto

Has sido asignado para coordinar un proyecto, pero posiblemente no tengas una preparación formal al respecto. Si piensas que administrar un proyecto significa seguir haciendo lo mismo que has hecho hasta ahorita y esperar las alabanzas de tu equipo de trabajo, estás muy equivocado.

Puede ser que tengas que seguir realizando en parte algunas de las actividades que has realizado hasta el momento (por ejemplo programar parte de la aplicación de software). Pero, eso sólo significa que tienes responsabilidades de otros roles, además de la del administrador de proyectos. Las tareas del líder de proyecto son muy diferentes a las de un operativo.

Seguramente te servirá contar con una guía rápida para tener una visión de por dónde avanzar dentro del proyecto. A continuación te mostramos esta guía que no pretende más que mostrar los elementos y tareas básicas de las cuales tendrás que responsabilizarte dentro del proyecto.

1. Conoce tu proyecto.

En primer lugar debes de tener claro qué es lo que se busca con este proyecto. Cuál es el objetivo a cumplir. ¿Desarrollar un software de control de recursos? ¿Construir una casa? ¿Diseñar un automóvil? ¿Organizar una boda? Identifica quiénes son todas las personas que te pueden proporcionar información respecto a lo que se necesita. Hay proyectos en los que una sola persona cuenta con toda la información, o es quien debe quedar satisfecho con el resultado. Pero, en la mayoría de los proyectos son varias las personas interesadas en el resultado del proyecto. Ubícalos bien y cuestiónalos sobre el mayor detalle posible de lo que esperan. Determina claramente los requerimientos del proyecto.

2. Planea las actividades, tiempos y recursos.

Una vez que determinas con la mayor claridad y detalle posible lo que debes de desarrollar durante el proyecto (las funciones del software, las características de la casa, los detalles de la boda, etc), entonces puedes iniciar el trabajo de planeación. Planeas las actividades necesarias, planeas la cantidad de gente y el perfil necesario para realizar las actividades, planeas el esfuerzo que cada una de ellas tendrá que realizar, planeas los tiempos necesarios para completar cada tarea y para completar el trabajo completo, cuidando que no haya tiempos muertos ni ningún tipo de desperdicio de recursos. Si el proyecto sale mal, lo peor que puedes hacer es echarle la culpa a tu equipo de trabajo, finalmente tú debes de poder decidir si es el personal que podrá cumplir el trabajo o no.

Mucha gente comienza a trabajar en cuanto tiene una idea leve de los resultados que se esperan, sin detenerse a pensar cómo llegará a ese objetivo ni cuándo lo hará. Si nadie te presiona por los recursos o tiempo que consumas para lograrlo, esta puede ser una fórmula cómoda, aunque no esperes que confíen en ti cuando se trate de proyectos estratégicos para la empresa donde el control de los recursos sea importante. Es bastante probable que en realidad simplemente estés ejecutando, y no administrando el proyecto.

3. Ejecuta y monitorea el proyecto, manteniendo la visibilidad hacia el exterior.

He conocido proyectos que terminan mucho más tarde de lo que se planeó, pero con clientes contentos. Y he conocido proyectos que terminan a tiempo, pero donde los clientes terminan odiando al equipo de trabajo. Una razón importante para esto es la forma en que se haya monitoreado el proyecto y generado visibilidad hacia el exterior. Una vez diseñado el plan hay que seguirlo, y para lograr esto debes de monitorearlo constantemente para reaccionar oportunamente. ¿Ya inició la gente el trabajo que le corresponde? ¿Ya terminó el trabajo que debía de terminar? ¿Por qué se está atrasando? ¿Cuánto se está desviando? ¿Qué puedes hacer para que no se siga retrasando? Monitorear el proyecto significa mantenerse al pendiente de lo que ocurre. No esperes que por el simple hecho de que ya elaboraste un plan, éste se va a cumplir mágicamente. Si no hay nadie que le dé seguimiento, difícilmente se cumplirá. Además, no sólo tú, como líder de proyecto quieres mantenerte informado de lo que ocurre. También tu jefe y el cliente quieren saberlo, así que es mejor que los mantengas continuamente informados de lo que ocurre para que juntos vayan tomando decisiones para corregir las desviaciones contra lo planeado, y evitar sorpresas en los resultados.

4. Aprende de tus errores.

En todo proyecto ocurren cosas buenas que deberías de volver a repetir en tus proyectos futuros, y cosas malas que deberías de evitar. Es parte del aprendizaje, y es lo que te ayudará en gran medida a que tus resultados sean cada vez mejores. Si compartes este conocimiento, tus compañeros y tu empresa crecerán profesionalmente sin necesidad de enfrentarse a los mismos problemas que tú. Einstein dijo alguna vez que no hay nada peor que hacer las cosas igual y esperar resultados diferentes. Si ya descubriste que hay cosas que ocasionan retrasos y problemas en tus proyectos, no lo vuelvas a repetir. Y si viste que hubo actividades que ayudaron al éxito del proyecto entonces procura volver a realizarlas. Claro que no se trata de redescubrir el hilo negro, hay muchas buenas prácticas allá afuera que puedes aprender de bibliografía, internet y cursos que te ayudarán a realizar cada día un mejor trabajo.

Green Project Management ¿Nueva tendencia en administración de proyectos?

Por Dave Shirley y Rich Maltzman

Hablar de Green Project Management es mucho más que salvar al medio ambiente (no quiere decir que esto no sea un noble esfuerzo). Los administradores de proyectos siempre han sido verdes, tal vez sin que ellos lo sepan. Por definición, los project managers están intentando constantemente reducir costos, incrementar el valor para los stakeholders y proteger los escasos recursos, lo que quiere decir que ellos han asumido una postura verde. En nuestra mente, todos los procesos que se emplean para cumplir los objetivos de la administración de proyectos, han sido simplemente fragmentados y les falta la etiqueta de medioambiente.

¿Recuerdan cuando la administración de proyectos fue considerada una “profesión accidental?. Con la ayuda de organizaciones como el Project Management Institute (PMI®) y el trabajo duro de una gran cantidad de personas, los project managers están encabezando los cambios necesarios para continuar con la viabilidad del negocio, de allí que la administración de proyectos hoy por hoy es una opción profesional muy demandada.

Con la tendencia hacia los negocios verdes, sentimos que el project

manager es “accidentalmente verde”, y no necesita serlo. Las mismas disciplinas, estándares y métodos que han hecho del administrador de proyectos una parte integral de los entornos de negocios pueden ser aplicadas en ambientes de negocios verdes, lo que resulta en un enfoque estructurado para el green project management. Solamente veamos con un poco de profundidad dentro de la administración de proyectos verde y lo que encontraremos será lo que es hoy en día un project manager.

Si la administración de proyectos es más que salvar al medio ambiente ¿por qué la administración de proyectos necesita tener una etiqueta que lo califique como “verde”?. Si eres un amante de los árboles o escéptico, hay una creciente “ola verde” de ambientalismo. Tú puedes navegarla o simplemente mirarla desde la orilla y ésta no va a desaparecer. Los project managers ven a sus proyectos a través de muchos lentes: finanzas, calendario, calidad. Muchos expertos y conocedores de la materia creen que un proyecto también debería ser visto a través del lente medioambiental para que el project team incremente su forma de pensar a largo plazo y aprovechen la ola verde. También tiene sentido simplemente desde un punto de vista profesional. Sólo en los Estados Unidos, 130 billones de dólares se han dispuesto para proyectos relacionados con la energía como parte del estímulo del gasto del gobierno.

Pero ¿qué es lo que miras cuando ves a través del lente medioambiental?. ¿Cómo esa ayuda define el green project management?. Mirar a través de este lente, le permite a los project managers buscar y ver las oportunidades dentro de un proyecto para ahorrar en los recursos escasos y plantearse preguntas como: ¿En qué parte de los procesos como diseñar, planificar, ejecutar , cerrar y más allá podemos ahorrar energía?. No estamos hablando solamente de las emisiones de carbono. También nos referimos a la energía humana, aunque esto puede traducirse de nuevo como la huella de carbono. Por ejemplo, es más eficiente tener juntas virtuales que tener que trasladarse para sostener reuniones cara a cara. Con todos los avances tecnológicos existentes en la actualidad, realizar una videoconferencia es muy fácil, económico y hasta divertido, es casi como estar allí en

persona, excepto que se ahorra tiempo en traslado, dinero y por supuesto, el consumo de combustibles fósiles.

Si las posibilidades lo permiten, ¿debería de equiparse a los miembros del equipo del proyecto con e-readers para que ellos puedan descargar todos los documentos y de ese modo se ahorraría papel?. ¿Eso no haría más conveniente mantener y revisar los últimos documentos sin tener que hacer el esfuerzo de prender la computadora, ahorrado así energía humana y de otros tipos?.

Esas son solamente un par de cosas a considerar por el equipo del proyecto, específicamente si ellos trabajan de forma remota (como parece ser la tendencia en estos días). Sin embargo, hay muchas más razones que ayudan a ser verdes a los project managers.

Nosotros no creemos que el green project management esté limitado al manejo de aspectos medioambientales de un proyecto. Sentimos que está conectado con la responsabilidad social corporativa, la triple línea de fondo, los cuatro rasgos de sustentabilidad de Natural Step, y las 4 Ls en inglés (Lean, Learn, Linked and Lasting; Reducir, Aprender, Vincular y Durabilidad).

La administración de proyectos verde se trata de personas, el planeta y rentabilidad, pero también es acerca de: eliminar nuestra contribución a la acumulación de químicos tóxicos (DDT, PCB), erradicar nuestra contribución a la destrucción de la naturaleza y eliminar nuestra contribución a quitar la capacidad de los seres humanos para satisfacer sus necesidades.

Finalmente, la administración de proyectos verde es: reducir desperdicios y hacer que las operaciones sean más eficiente; compartir las lecciones aprendidas para el crecimiento organizacional; conectar a las empresas con el plan de administración medioambiental y pensar a largo plazo. Hacer esto, por supuesto que ayuda al planeta, pero este tipo de pensamiento también repercutirá en el éxito del proyecto y de la organización.

Sin duda, eso suena a mucha responsabilidad puesta sobre los hombros del project manager. Pero los administradores de proyectos ya cuentan con las habilidades inherentes y la experiencia para realizar sus proyectos con una intención verde. Esto es lo que hay que hacer, porque afectará de forma positiva la triple línea de fondo y ayudará al equipo del proyecto a hacer las cosas correctas.

Modelos

Estructura del PMBOK®

Por Mauricio Morales, PMP

El Project Management Institute (PMI®) creó, en 1996, la primera edición de “A Guide to the Project Management Body of Knowledge” llevando al mundo un documento que, poco a poco, fue calando en las industrias y en la administración de proyectos, convirtiéndose en un estándar avalado por ANSI en el año 2000 con su segunda edición. Actualmente, en su cuarta edición de 2008, el PMBoK® es el documento de referencia obligado para cualquier persona que desee mejorar su gerencia de proyectos, certificarse o

simplemente incrementar el éxito de sus proyectos; y para cualquier organización que desee implementar procesos y metodologías eficaces para lograr el éxito de sus proyectos.

El boom del PMBoK® se da desde el año 2000 cuando tuvo lugar una fuerte importante evolución del estándar (y cuando se empezó a cobrar, ya que el de 1996 había sido gratuito).

El PMBoK® compite con otros modelos de gerencia de proyectos como el de la Association for Project Management (APM) y Prince (en Reino Unido); sin embargo, se ha posicionado a nivel mundial como estándar de gerencia de proyectos y las certificaciones otorgadas sobre este, como Certificate Associate in Project Management (CAPM®) y Project Management Professional (PMP®) son las más reconocidas por las empresas y las más buscadas por los practicantes.

El PMBoK® es un compendio de mejores prácticas, agrupadas de cierta manera, heredadas de diversas industrias y disciplinas que conforman un modelo metodológico. El PMBoK® en sí no es una metodología que “deba” ser seguida al pie de la letra; de hecho, el mismo documento, indica que los procesos y sus relaciones deben ser personalizados a las necesidades del proyecto y de la empresa. El PMBoK® es sólo una guía, muy completa y elaborada, de lo que normalmente un gerente de proyectos debe llevar a cabo, explicado en un buen nivel de detalle y separando procesos que normalmente se llevan a cabo de forma simultánea.

Como modelo, el PMBoK® no nos indica cómo se hacen las cosas, al igual que CMMi® pero es más explícito que éste en la definición de los procesos o prácticas a llevar a cabo, estableciendo una serie de entradas, técnicas y salidas para cada uno.

ESTRUCTURA

El PMBoK® establece la administración de proyectos como un conjunto de nueve áreas de conocimiento que deben ser dominadas por el project manager y que contienen una serie de procesos que corresponden a los pasos necesarios para que sean completamente cubiertas. Cada proceso establece unas entradas (documentos), técnicas (mejores prácticas) y salidas (nuevamente documentos). Tanto las entradas como las salidas conectan a los diferentes procesos entre sí para formar una completa red sobre la que se puede establecer una metodología.

El PMBoK® puede verse de dos formas diferentes, cual si fuera una matriz que puede leerse por columnas o filas. La forma estándar como está estructurado el documento establece áreas de conocimiento. La forma útil para el gerente de proyectos y la organización es, sin embargo, por grupos de procesos de Inicio, Planeación, Ejecución, Control y Cierre.

REPRESENTACIÓN POR ÁREAS DE CONOCIMIENTO

Las áreas de conocimiento definidas en el PMBoK® son:

Gestión de Integración – Procesos requeridos para integrar todas las actividades, documentos y recursos del proyecto.

Gestión de Alcance – Procesos requeridos para identificar todo el trabajo requerido y sólo el trabajo requerido para obtener los entregables del proyecto y cumplir los objetivos.

Gestión de Tiempo – Procesos requeridos para asegurar que el proyecto es finalizado a tiempo. Gestión de Costos – Procesos requeridos para asegurar que el proyecto es finalizado dentro de

un presupuesto aprobado. Gestión de Calidad – Procesos requeridos para asegurar que el proyecto cumple los

requerimientos y necesidades por los cuales fue emprendido. Gestión de Comunicaciones – Procesos requeridos para asegurar la generación, distribución,

almacenamiento y disposición última de toda la información del proyecto, a tiempo y de forma adecuada.

Gestión de Recursos Humanos – Procesos requeridos para administrar eficientemente la gente que participa en el proyecto.

Gestión de Riesgos – Procesos requeridos para identificar, analizar y responder efectivamente a los riesgos del proyecto.

Gestión de Adquisiciones – Procesos requeridos para adquirir bienes y servicios fuera de la organización del proyecto.

Cada área de conocimiento incluye varios procesos que se presentan en la siguiente tabla:

Ilustración 1 - Áreas de Conocimiento de la Gerencia de Proyectos con sus Procesos Internos

REPRESENTACIÓN POR GRUPOS DE PROCESO

Como se puede apreciar en el segmento anterior, la estructura del PMBoK® por áreas de conocimiento da una interesante clasificación de procesos y conocimientos a ser dominados por el líder de proyectos pero, seamos honestos, es difícil seguir esta estructura a lo largo de un proyecto. Es como intentar armar un rompecabezas con las piezas hacia abajo, cuando no se aprecia una conexión entre las mismas, más allá de su forma.

Debido a la aparente desconexión entre procesos y áreas, el PMBoK® también define una estructura por grupos de procesos. Estos grupos son simplemente la secuencia lógica que sigue cualquier proyecto: Inicio, Planeación, Ejecución, Control y Cierre.

La secuencia de los grupos de procesos varió de la planteada en PMBoK® 1996 y 2000 a la descrita en las ediciones 3ª y 4ª. A continuación presentamos ambas representaciones.

Ilustración 2 - Representación de Grupos de Procesos en PMBoK 1996 y 2000

En esta representación el énfasis se encuentra en las interrelaciones de los grupos de procesos, en donde se evidencia un ciclo permanente entre planeación, ejecución y control que claramente indica que la planeación no está escrita sobre piedra y que debe ser modificada de acuerdo a la situación del proyecto en un momento particular.

Ilustración 3 - Representación de Grupos de Procesos del PMBoK 2004 y 2008

En esta última representación se ha llevado la estructura de procesos a una forma acorde con el modelo de mejoramiento continuo de Edward Deming, PHVA, promulgado desde la versión 2004. Evidencia también un ciclo entre planeación y ejecución pero siempre sobre una base permanente de seguimiento y control. Dentro de cada uno de los grupos de proceso se encuentran ahora los procesos de las áreas de conocimiento, conectados entre sí de una manera secuencial y lógica, que permite un seguimiento natural por parte del gerente de proyecto y determina una forma de evolución del proyecto y de los documentos.

A continuación presentamos los procesos subyacentes dentro de los grupos de procesos:

Ilustración 4 - Procesos de Inicio del Proyecto según el PMBoK 2008

Ilustración 5 - Procesos de Planeación del Proyecto según el PMBoK 2008

Ilustración 6 - Procesos de Ejecución del Proyecto según el PMBoK 2008

Ilustración 7 - Procesos de Control del Proyecto según el PMBoK 2008

Ilustración 8 - Procesos de Cierre del Proyecto según el PMBoK 2008

BIBLIOGRAFÍA

Carnegie Mellon Software Engineering Institute, CMMi® for Development Version 1.2, CMMi-DEV, V 1.2, CMU/SEI-2006-TR-008

Project Management Institute, A Guide to the Project Management Body of Knowledge 4th Edition, 2008.

Morales, Mauricio F., Diplomado en Gerencia de Proyectos Sobre la Base Metodológica del PMBoK®, 2001 – 2009, U-Mynd Ltda.

Sherer, Wayne. Contrasting CMMi and the PMBoK, CMMi Technology Conference and User Group, Noviembre 2005.

Sherer, Wayne / Thrasher, Sandy. CMMi and PMBoK Mappings, 2005.

La implementación de CMMI® desde la perspectiva del PMBOK®


CMMi® y PMBoK®. Dos de las más reconocidas siglas a nivel mundial y sinónimo de calidad, organización, proceso, formalismo, reconocimiento, mejoramiento. Sin embargo, también representan, para muchas empresas o personas algo complejo, difícil, largo, costoso, impráctico. Sobre todo, costoso.

Por un lado, CMMi® ha sido renombrado a nivel mundial como estándar de medición de calidad de los procesos de una organización, desde que en 1987 el Departamento de Defensa de los EE.UU. (DoD) logró su definición (CMM en ese momento) por parte del patrocinado Software Engineering Institute (SEI) de la Universidad de Carnegie-Mellon. Recientemente empezó a regir la versión 1.2 del modelo integrado CMMi® que, curiosamente, nuevamente se ha desintegrado para entregar varios sabores, a saber, CMMi® for Development, CMMi® for acquisition y últimamente CMMi® for Services, permitiendo, con este último, cubrir cualquier tipo de organización que produzca servicios y no productos.

Por otro lado, PMBoK®, siglas de Project Management Body of Knowledge, término acuñado por el Project Management Institute (PMI®) y que indica que su contenido se extrae del conocimiento global sobre el tema; lanzado en 1996 como un abrebocas al boom que se avecinaría con su segunda edición del año 2000 y que ya se encuentra en su cuarta edición. Orientado a personas que se han especializado en gerencia de proyectos y que busca formalizar y profesionalizar las actividades, un tanto oscuras hasta hace poco, del administrador de proyectos de cualquier industria.

La primera, orientada a empresas, la segunda orientada a personas. ¿Cómo se pueden relacionar? ¿Cómo se pueden aprovechar? ¿Pueden ser complementados, acoplados o diferenciados en la implantación? ¿Me sirve uno para llegar al otro?.

CMMi® y PMBoK® son dos modelos que se han convertido en estándares de mejoramiento e implementación de buenas prácticas enfocados, el primero a mejoramiento organizacional, ingeniería y proyectos de ingeniería, el segundo a proyectos de cualquier índole a cualquier nivel en una organización, sin obligar a una implantación a través de la misma.

CMMi® y PMBoK® tienen puntos importantes de encuentro en donde PMBoK®, con sus procesos, apoya la consecución de metas específicas y genéricas de CMMi® en los niveles de madurez 2 a 4 con obvias diferencias en áreas de ingeniería o aspectos de proceso que no son competencia del PMBoK®.

El nivel de acoplamiento de las prácticas de CMMi® y metas tanto específicas como genéricas con los procesos, entradas, técnicas y herramientas y salidas del PMBoK® es alto, permitiendo llegar a grandes fortalezas en el primero, a través del segundo.

Un proceso de mejoramiento llevado a cabo sobre las mejores prácticas definidas por el PMBoK® permite cerrar la brecha entre lo que se debe hacer y cómo se debe hacer pues establece un adecuado nivel de detalle que permite seleccionar las prácticas pero con la libertad de determinar la formalidad de la implementación.

Se puede llevar a cabo un proceso de mejoramiento hacia CMMi® partiendo desde PMBoK® con un cierre adicional de brechas en prácticas de ingeniería y procesos en niveles superiores de madurez.

Para todo el mejoramiento se requerirá un fuerte componente de entrenamiento a nivel organizacional para lograr la mayor concientización posible sobre lo que se espera y se requiere desarrollar.

BIBLIOGRAFÍA






Áreas de CMMI relacionadas con la administración de proyectos


Podría existir alguna relación entre ciertos procesos del PMBoK® y las Áreas de Proceso (PAs) de CMMi®; sin embargo, la relación está más a nivel de prácticas de CMMi® con procesos del PMBoK®.

En un análisis detallado, no todos los procesos del PMBoK® son referenciados en CMMi®; sin embargo, aplicar todos los procesos del PMBoK® a una metodología organizacional de proyectos crea fortalezas en varios de los niveles de madurez de CMMi®.

La siguiente imagen presenta uno de los procesos del PMBoK® que puede ser relacionado, directamente, con una práctica de PP de CMMi®. El PMBoK® describe, con algún nivel de detalle, cada uno de los elementos de las entradas, técnicas y salidas. Para algunos de ellos incluye ejemplos gráficos y explicaciones adicionales.

Ilustración 1 - Diagrama de un Proceso de Gerencia de Proyectos con Entradas, Técnicas y Salidas

A continuación se presenta la práctica específica del área de proceso de Planeación del Proyecto que se relaciona de manera directa con el proceso de arriba, tal cual como se encuentra en el documento de CMMi®.

Tabla 1 - Área de Proceso de CMMi con Descripción Completa

Level 2 Process Area PROJECT PLANNING Goal SG 1 Establish Estimates

Estimates of project planning parameters are established and maintained. Practice SP 1.1 Estimate the Scope of the Project

Establish a top-level work breakdown structure (WBS) to estimate the scope of the project. The WBS evolves with the project. Initially a top-level WBS can serve to structure the initial estimating. The development of a WBS divides the overall project into an interconnected set of manageable components. Typically, the WBS is a product oriented structure that provides a scheme for identifying and organizing the logical units of work to be managed, which are called “work packages.” The WBS provides a reference and organizational mechanism for assigning effort, schedule, and responsibility and is used as the underlying framework to plan, organize, and control the work done on the project. Some projects use the term “contract WBS” to refer to the portion of the WBS placed under contract (possibly the entire WBS). Not all projects have a contract WBS (e.g., internally funded development).

Typical Work Products

1. Task descriptions 2. Work package descriptions 3. WBS

Subpractices 1. Develop a WBS based on the product architecture.

The WBS provides a scheme for organizing the project’s work around the product and product components that the work supports. The WBS should permit the identification of the following items:

Identified risks and their mitigation tasks Tasks for deliverables and supporting activities Tasks for skill and knowledge acquisition Tasks for development of needed support plans, such as configuration

management, quality assurance, and verification plans

Tasks for integration and management of nondevelopmental items

2. Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule.

The top-level WBS is intended to help in gauging the project work effort in terms of tasks and organizational roles and responsibilities. The amount of detail in the WBS at this more detailed level helps in developing realistic schedules, thereby minimizing the need for management reserve.

3. Identify product or product components that will be externally acquired.

Refer to the Supplier Agreement Management process area for more information about acquiring products from sources external to the project.

4. Identify work products that will be reused.

El detalle presentado en el PMBoK®, para la mayoría de los procesos, es mayor que el expuesto en CMMi®, sumando a esto, que el PMBoK® contiene procesos que no pueden ser direccionados a CMMi®. Por otro lado, CMMi® provee una estructura de gestión de procesos y mejores prácticas para ingeniería.

Combinando ambos modelos se obtiene un excelente y maduro esquema de gerencia de proyectos de ingeniería.

CMMI® DESDE PMBOK®

Por su especificidad, no es fácil establecer una visión del PMBoK® desde CMMi® o mejor, hay mucho más que abarcar desde CMMi® que desde PMBoK®; sin embargo, al revés, PMBoK® permite implantar una gerencia de proyectos más amplia que la descrita por CMMi® y soporta algunas prácticas de otras disciplinas como soporte.

Para enfocarnos mejor en CMMi® y cómo podemos apoyarnos en conseguirlo con PMBoK® recorreremos las prácticas de CMMi® indicando cómo son apoyadas por los procesos de aquel.

COMPARACIÓN DIRECTA DE ÁREAS DE PROCESO CMMI® A PROCESOS PMBOK®

Desde PMBoK® se apoyan varias áreas de proceso o prácticas específicas y genéricas de CMMi®. Dado que una valoración oficial busca el cumplimiento o logro de las metas específicas y genéricas, buscaremos cuáles de éstas se encuentran cubiertas por los procesos del PMBoK®. Esta comparación se realiza en la siguiente tabla, para todas las PA de CMMi®, en todos los niveles de madurez.

Tabla 2 - Comparación de Prácticas Específicas de las Áreas de Proceso de CMMi contra Procesos del PMBoK

Nivel Área de Proceso

CMMi® Metas Específicas de las

Áreas de Proceso de CMMi®Proceso del PMBoK®

Correspondiente o Equivalente REQM – Gestión de Requerimientos

SG 1 – Administrar requerimientos

5.2 – Definir alcance 5.5 – Controlar el alcance

SG 1 – Establecer estimados

5.3 – Desarrollar WBS 6.3 – Estimar Recursos de las Actividades 6.4 – Estimar duración de las actividades7.1 – Estimar costos 7.2 – Determinar el presupuesto

SG 2 – Desarrollar un plan de proyecto

4.2 – Desarrollar plan del proyecto 8.1 – Planear la calidad 9.1 – Planear recursos humanos 10.2 – Desarrollar plan de comunicaciones 11.1 – Planear gestión de riesgos 12.1 – Planear adquisiciones

PP – Planeación de Proyectos

SG 3 – Obtener compromiso con el plan

4.2 – Desarrollar plan del proyecto PMBoK® define que el plan se desarrolla con el equipo del proyecto para obtener mayor compromiso.

2

PMC – Monitoreo y Control de Proyectos SG 1 – Monitorear el proyecto

contra el plan

4.4 – Monitorear y controlar el trabajo del proyecto 5.4 – Verificar el alcance 5.5 – Controlar el alcance 6.6 – Controlar el cronograma 7.3 – Controlar costos 8.3 – Realizar control de calidad

11.6 – Monitorear y controlar riesgos 12.3 – Administrar adquisiciones

SG 2 – Administrar acciones correctivas hasta el cierre

4.4 – Monitorear y controlar el trabajo del proyecto 8.3 – Realizar control de calidad

SG 1 – Objetivamente evaluar procesos y productos de trabajo

8.2 – Realizar el aseguramiento de calidad 8.3 – Realizar control de calidad

PPQA – Aseguramiento de calidad de proceso y producto SG 2 – Proveer conocimiento y

evidencia objetivos

8.2 – Realizar el aseguramiento de calidad 10.5 – Reportar el desempeño

SG 1 – Alinear medición y actividades de análisis

7.1 – Estimar costos PMBoK® define, aunque no en un proceso, la realización de un Plan de Gestión de Costos en dónde se deben establecer las reglas de medición de valor ganado 7.3 – Controlar costos 4.4 – Monitorear y controlar el trabajo del proyecto 8.1 – Planear la calidad

MA – Medición y Análisis

SG 2 – Proveer resultados de las mediciones

4.4 – Monitorear y controlar el trabajo del proyecto 10.5 – Reportar el desempeño

SG 1 – Establecer acuerdos con proveedores

12.1 – Planear adquisiciones 12.2 – Ejecutar adquisiciones

SAM – Administración de Acuerdos con Proveedores

SG 2 – Satisfacer acuerdos con proveedores

12.3 – Administrar adquisiciones12.4 – Cerrar adquisiciones

SG1 – Establecer líneas base

5.3 – Desarrollar WBS 6.5 – Desarrollar el cronograma 7.2 – Determinar el presupuesto 8.1 – Planear la calidad

SG 2 – Rastrear y controlar cambios

8.2 – Realizar el aseguramiento de calidad 8.3 – Realizar control de calidad 4.5 – Ejecutar el control integrado de cambios En PMBoK® La mayoría de los procesos de planeación y control tienen, como salida, solicitudes de cambios, actualizaciones a documentos del proyecto y/o actualizaciones al plan del proyecto.

CM – Administración de la configuración

SG 3 – Establecer integridad

4.2 – Desarrollar plan del proyecto 4.4 – Monitorear y controlar el trabajo del proyecto 4.5 – Ejecutar el control integrado de cambios 10.2 – Desarrollar plan de comunicaciones

DAR – Análisis y resolución de decisión

SG 1 – Evaluar alternativas

6.5 – Desarrollar el cronograma 7.1 – Estimar costos 7.2 – Determinar el presupuesto PMBoK® establece análisis de alternativas como técnica en estos procesos, junto con el análisis “what-if”; sin embargo, no lo determina en el nivel de formalismo que establece CMMi® pues se asume que habrá algún método para realizarlo.

SG 1 – Usar el proceso definido para el proyecto

4.2 – Desarrollar plan del proyecto 4.3 – Dirigir y gestionar la ejecución del plan del proyecto 4.4 – Monitorear y controlar el trabajo del proyecto 8.2 – Realizar el aseguramiento de calidad 10.3 – Distribuir información

3

IPM – Gerencia integrada de proyectos

SG 2 - Coordinar y colaborar con los stakeholders relevantes

5.1 – Obtener requerimientos 5.2 – Definir alcance 10.1 – Identificar stakeholders 10.4 – Administrar expectativas de los stakeholders 9.1 – Planear recursos humanos 9.2 – Adquirir el equipo del proyecto

9.3 – Desarrollar el equipo del proyecto9.4 – Administrar el equipo En PMBoK® el stakeholder es relevante para todas las actividades del proyecto y siempre se establece que sus necesidades y expectativas deben ser cumplidas.

SG 3 – Aplicar principio de IPPD IPPD en CMMi® se refiere a crear un ambiente de integración entre equipos para cumplir eficientemente con los requerimientos del proyecto y producir productos de calidad

SP 3.1 Establish the Project’s Shared Vision

SP 3.2 Establish the Integrated Team Structure

SP 3.3 Allocate Requirements to Integrated Teams

SP 3.4 Establish Integrated Teams Establish and maintain integrated teams in the structure.

SP 3.5 Ensure Collaboration among Interfacing Teams

4.1 – Desarrollar el project charter 5.1 – Obtener requerimientos 5.2 – Definir alcance 5.3 – Desarrollar el WBS 9.1 – Planear recursos humanos 9.2 – Adquirir el equipo del proyecto 9.3 – Desarrollar el equipo del proyecto9.4 – Administrar el equipo 8.2 – Realizar el aseguramiento de calidad 10.1 – Identificar stakeholders 10.2 – Desarrollar plan de comunicaciones 10.3 – Distribuir información 10.4 – Administrar expectativas de los stakeholders PMBoK® menciona, aunque no lo establece como proceso ni técnica, la creación de la Matriz de Asignación de responsabilidades (RAM) donde se asignan paquetes del WBS a personas o equipos del proyecto.

SG 1 – Establecer activos de procesos organizacional

10.3 – Distribuir información 4.6 – Cerrar el proyecto o fase PMBoK® no define cómo establecer los activos de proceso pero sí los usa como entrada para la mayoría de sus procesos y explícitamente en estos dos, los activos de proceso son actualizados.

OPD – Definición del Proceso Organizacional

SG 2 – Habilitar la gestión de IPPD

SP 2.1 Establish Empowerment Mechanisms

SP 2.2 Establish Rules and Guidelines for Integrated Teams

SP 2.3 Balance Team and Home Organization Responsibilities

10.1 – Identificar stakeholders 10.2 – Desarrollar plan de comunicaciones 5.3 – Desarrollar WBS 9.1 – Planear recursos humanos 9.3 – Desarrollar el equipo del proyectoPMBoK® no posee procesos específicos pero si define técnicas de negociación, creación de reglas básicas y esquemas de comunicación que cubren las prácticas específicas de esta meta específica.

SG 1 – Determinar oportunidades de mejoramiento del proceso

8.1 – Planear la calidad 8.2 – Realizar el aseguramiento de calidad 8.3 – Realizar control de calidad 10.5 – Reportar el desempeño

SG 2 – Planear e implementar mejoramientos al proceso

8.1 – Planear la calidad 8.2 – Realizar el aseguramiento de calidad PMBoK® no contiene procesos para implementar o hacer seguimiento, de manera específica, al mejoramiento del proceso; sin embargo, como salida del 8.1 hay un Plan de Mejoramiento del Proceso y como salida de 8.2 hay actualizaciones a documentos del proyecto que incluyen las oportunidades de mejora.

OPF – Foco en el Proceso Organizacional

SG 3 – Implantar activos de proceso organizacional e incorporar lecciones

10.3 – Distribuir información En PMBoK®, en la mayoría de los procesos de planeación y control, se

cuenta con los activos de proceso como entrada o son alimentados en las salidas; estos incluyen las lecciones aprendidas para que sean incluidas en el plan Aunque no hay un proceso específico, como salida del 10.3 están las lecciones aprendidas

SG 1 – Prepararse para la integración de producto

No cubierta por PMBoK®

SG 2 – Asegurar compatibilidad de interfaces

5.1 – Obtener requerimientos 5.2 – Definir alcance 8.3 – Realizar control de calidad PMBoK® no establece directamente nada relacionado con interfaces pero si se obtienen como requerimientos se asegura su cumplimiento hasta el final

PI – Integración de producto

SG 3 – Ensamblar componentes de producto y entregar el producto

4.6 – Cerrar el proyecto o fase 5.4 – Verificar el alcance PMBoK® no se refiere a actividades de ingeniería como el ensamble pero en estos dos procesos asegura la aceptación y entrega del producto del proyecto o la fase a otros.

SG 1 – Desarrollar requerimientos del cliente

5.1 – Obtener requerimientos 5.2 – Definir alcance

SG 2 – Desarrollar requerimientos del producto


RD – Desarrollo de Requerimientos

SG 3 – Analizar y validar requerimientos


SG 1 – Prepararse para la gestión de riesgos

11.1 – Planear Gestión de Riesgos

SG 2 – Identificar y analizar riesgos

11.2 – Identificar riesgos del proyecto 11.3 – Ejecutar análisis cualitativo de riesgo 11.4 – Ejecutar análisis cuantitativo de riesgos RSKM – Gestión de

Riesgos

SG 3 – Mitigar riesgos

11.5 – Planear respuestas a riesgos PMBoK® excede los requisitos de CMMi en cuanto a la gestión de riesgos extendiendo el alcance hasta el monitoreo y control y definiendo acciones adicionales a la mitigación como transferir, evitar, asumir y contener.

SG 1 – Seleccionar soluciones para componentes de producto


SG 2 – Desarrollar el diseño No cubierta por PMBoK® TS – Solución Técnica

SG 3 – implementar el diseño del producto


SG 1 – Prepararse para la verificación

8.1 – Planear la calidad

SG 2 - Ejecutar revisiones por pares

No cubierta por PMBoK® aunque como técnica en el 8.3 – Realizar control de calidad, se incluyen las inspecciones, no se menciona que sean por pares.

VER – Verificación

SG 3 – Verificar productos de trabajo seleccionados

8.2 – Realizar el aseguramiento de calidad 8.3 – Realizar control de calidad

SG 1 – Prepararse para la validación

8.1 – Planear la calidad

VAL – Validación SG 2 - Validar el producto y los componentes de producto

8.3 – Realizar control de calidad

SG 1 – Establecer la capacidad de entrenamiento organizacional

No cubierta por PMBoK® OT – Entrenamiento organizacional SG 2 – Proveer el

entrenamiento necesario 9.1 – Planear recursos humanos 9.3 – Desarrollar el equipo del proyecto

4 QPM – Gestión Cuantitativa de Proyectos

SG 1 – Administrar cuantitativamente el proyecto

5.5 – Controlar el alcance 7.3 – Controlar costos 8.2 – Realizar el aseguramiento de calidad 8.3 – Realizar control de calidad

SG 2 – Administrar estadísticamente el desempeño de los subprocesos

8.3 – Realizar control de calidad PMBoK® establece herramientas y técnicas estadísticas de control de procesos como las tablas de control en este proceso.

OPP – Desempeño del Proceso Organizacional

SG 1 – Establecer líneas base de desempeño y modelos

7.2 – Determinar el presupuesto En PMBoK®, como salida de este proceso, se establece la Línea Base de Medición de Desempeño del proyecto que se operará a través del método de Valor Ganado

OID – Innovación y Despliegue Organizacional

SG 1 – Seleccionar mejoramientos


5

SG 2 – Desplegar mejoramientos


Analizando la tabla podemos darnos cuenta que se puede lograr un muy amplio cubrimiento de CMMi® con los procesos, técnicas, entradas y salidas del PMBoK®; sin embargo, debe llevarse a cabo un proceso de definición cuidadoso de los métodos y prácticas que se vayan a implementar para lograr cubrimiento completo.

COMPARACIÓN DE METAS GENÉRICAS CMMI® A PROCESOS DE PMBOK®

Si bien es importante que haya apoyo del PMBoK® para las prácticas específicas o algunas áreas de proceso, también lo es el que las prácticas genéricas sean apoyadas ya que determinan la institucionalización y mejoramiento del proceso en la organización.

A continuación presentamos la relación entre estas prácticas genéricas de CMMi® y los procesos del PMBoK®.

Tabla 3 - Comparación de Metas Genéricas de CMMi contra Procesos del PMBoK

Práctica Genérica PMBoK® GP 2.1 – Establecer una política organizacional PMBoK® define como entradas a muchos de sus

procesos los Activos de Proceso de la Organización y se refiere, en Gestión de Calidad, a la inclusión de la Política de Calidad de la organización. Asume, entonces, que las políticas organizacionales ya se encuentran en estos activos de proceso.

GP 2.2 – Planear el proceso 4.2 – Desarrollar el Plan del Proyecto GP 2.3 – Proveer recursos 6.3 – Estimar Recursos de las Actividades GP 2.4 – Asignar responsabilidades 4.1 – Desarrollar el Project Charter (Responsabilidad para

el gerente de proyecto) 9.1 – Planear Recursos Humanos (Responsabilidades del equipo del proyecto)

GP 2.5 – Entrenar la gente 9.3 – Desarrollar el Equipo del proyecto GP 2.6 – Administra configuraciones 4.4 – Monitorear y Controlar el Trabajo del Proyecto GP 2.7 – Identificar e involucrar stakeholders relevantes

10.1 – Identificar Stakeholders

GP 2.8 – Monitorear y controlar el proceso 4.4 – Monitorear y Controlar el Trabajo del Proyecto 5.5 – Controlar el Alcance 6.6 – Controlar el Cronograma 7.3 – Controlar Costos 8.3 – Realizar control de calidad 11.6 – Monitorear y Controlar Riesgos 4.5 – Ejecutar el Control Integrado de Cambios

GP 2.9 – Objetivamente evaluar adherencia 8.2 – Realizar el Aseguramiento de Calidad GP 2.10 – Revisar estado con niveles superiores 10.5 – Reportar el Desempeño GP 3.1 – Institucionalizar un proceso definido No cubierta por PMBoK®

BIBLIOGRAFÍA






Integración de CMMi y del PMBOK® para proyectos exitosos


Existe una alta relación entre el PMBoK® y CMMi® por lo que llevar una implementación de prácticas de la mano del primero nos deja en una excelente posición, con fortalezas más allá de niveles 2 y 3.

El proceso de implementación sugerido, a través del PMBoK® se centra en la implantación de los procesos de gerencia de proyectos y en el cierre de las brechas que resulten con CMMi®. De esta manera se buscará implantar una adecuada gerencia de proyectos, llegando a CMMi® como una ganancia adicional, si se siguen los pasos adecuados.

Los pasos sugeridos para el proceso de implementación de CMMi® desde la gerencia de proyectos con PMBoK®, los hemos conceptualizado así:

1) DETERMINACIÓN DEL OBJETIVO DEL MEJORAMIENTO

Siempre el objetivo debe estar ligado a una meta de negocio, no a mejorar por mejorar. A través de la definición de la meta de negocio se obtiene el nivel de madurez deseado, si el mejoramiento se aborda por representación escalonada, o las áreas de proceso a mejorar, si se aborda la representación continua.

2) ESTABLECIMIENTO DE LA SITUACIÓN ACTUAL EN ADMINISTRACIÓN DE PROYECTOS

Podemos apoyarnos en el Organizational Project Management Maturity Model (OPM3®), otro de los estándares de gerencia de proyectos del PMI®, que nos permite evaluar el nivel de madurez de la organización en cuanto a la gerencia de proyectos se refiere, para determinar los aspectos de mejora o implantación de prácticas específicos, de acuerdo a la idiosincrasia, situación de la empresa, mercado y clientes objetivo, nivel y cantidad de personal, estructura organizacional y demás factores determinantes o limitantes de la formalidad y prácticas.

3) ESTABLECIMIENTO DE LA SITUACIÓN ACTUAL EN INGENIERÍA

Al igual que el proceso anterior, pero enfocado en aquellas actividades o procesos de ingeniería propios de la empresa. En esta área el PMBoK® no aporta en su totalidad por lo que deberemos referirnos a las áreas de proceso de ingeniería y a las mejores prácticas de la industria específica en que se lleve a cabo el mejoramiento.

4) ESTABLECIMIENTO DE LA SITUACIÓN ACTUAL EN GESTIÓN DE PROCESOS

Es muy importante tener una adecuada gestión de procesos. En esto nos apoyan las PAs OPD y OPF de nivel 3 de CMMi® que, en nuestro concepto y a pesar de que estén en nivel 3, deben iniciar su desarrollo desde nivel 2, junto con CM. El análisis de la situación en gestión de procesos nos permite establecer los trabajos previos de definición de estándares, documentación, archivos de procesos, biblioteca de procesos y demás elementos de soporte a la definición, documentación y despliegue de procesos y prácticas.

5) SOCIALIZACIÓN DE LA SITUACIÓN ACTUAL DE LA ORGANIZACIÓN

A través de presentaciones a grupos específicos y a alta gerencia, se presenta la situación actual y el objetivo de mejoramiento establecido, indicando el nivel de compromiso que se requiere para llegar a la meta y una estimación del tiempo del esfuerzo a realizar, bajo los supuestos adecuados de disponibilidad de personal y compromiso de la alta gerencia.

6) DESARROLLO DEL PLAN DE ENTRENAMIENTO EN ADMINISTRACIÓN DE PROYECTOS

Con base en las necesidades específicas encontradas en el análisis de situación actual en gerencia de proyectos, se establecen los puntos de entrenamiento en gerencia de proyectos. Dado que la gerencia de proyectos debe verse como política medular en la organización, se sugiere siempre llevar este entrenamiento al público más amplio posible y de la manera más completa, haciendo un enfoque claro en los logros que se ha planteado la organización.

7) DESARROLLO DEL PLAN DE ENTRENAMIENTO EN INGENIERÍA

Con base en las mejores prácticas que se ha identificado que requieren mejoramiento o implantación, cubriendo siempre las PAs de ingeniería del nivel deseado de madurez y apoyándose en las mejores prácticas de la industria objetivo de la organización.

8) DESARROLLO DEL PLAN DE ENTRENAMIENTO EN GESTIÓN DE PROCESOS

Si se requiere capacitar a la organización o a un área específica que se encargará de la administración de los procesos, se lleva a cabo este plan de entrenamiento. Como mínimo, para toda la organización deberá haber un entrenamiento de utilización de procesos y acerca de cómo se definen las solicitudes de mejoramiento y se tramitan, de acuerdo al nivel objetivo.

9) EJECUCIÓN DE PLANES DE ENTRENAMIENTO

Los entrenamientos planteados se llevan a cabo manteniendo un rastreo a los participantes, seguimiento al desarrollo de cada entrenamiento y una medición de efectividad y relevancia a lo largo de todo el proyecto, proveyendo los refuerzos que se requieran a lo largo del mismo.

10) DEFINICIÓN DE LOS EQUIPOS DE TRABAJO DE MEJORAMIENTO

Se puede observar que los entrenamientos no se discriminan a miembros específicos de la organización; obviamente se involucran en ingeniería los responsables de las actividades de ingeniería, sin embargo, para procesos y gerencia de proyectos se sugiere llevarlos al público más amplio posible.

Una vez dictados los entrenamientos, o a la par con los mismos, se definen los equipos que llevarán a cabo la definición de procesos, prácticas y el pilotaje y despliegue de los mismos.

11) DESARROLLO DEL PLAN DE IMPLEMENTACIÓN DE GESTIÓN DE PROCESOS

Este plan es específico para el equipo de mejoramiento de procesos y define la forma de atacar los puntos de mejora encontrados, el orden, la prioridad y las reglas del equipo.

12) DESARROLLO DEL PLAN DE MEJORAMIENTO DE GERENCIA DE PROYECTOS

Específicamente para el grupo a cargo del mejoramiento de la gerencia de proyectos. Es importante que en este grupo participen todos los gerentes, líderes o coordinadores de proyectos de la organización, quienes conocen la forma específica de trabajo.

13) DESARROLLO DEL PLAN DE MEJORAMIENTO DE INGENIERÍA

Enfocado en los puntos de mejora de ingeniería, se desarrolla con los practicantes técnicos de la organización, indicando las prácticas a implantar, seleccionadas de los entrenamientos y acordes con la compañía.

14) DISEÑO DE PRÁCTICAS

Cada uno de los equipos de mejoramiento diseña, entonces, las prácticas adecuadas para cubrir las oportunidades de mejora. Las prácticas deben ser adecuadas a la situación del personal, mercado, tipos de proyectos, duración, tipos de productos a desarrollar. Debe evitarse la sobre-formalización, cuando la organización no lo requiere o la utilización de prácticas demasiado densas si el personal no está acostumbrado a este nivel de formalidad.

15) VERIFICACIÓN DE PRÁCTICAS DISEÑADAS CONTRA MODELO CMMI®

Antes de pilotar las prácticas debe verificarse que cubran las brechas encontradas en la evaluación contra las prácticas de las PAs de CMMi®

16) PILOTAJE DE PRÁCTICAS

Una vez definidas las prácticas, se pilotan en proyectos específicos o situaciones que permitan evaluar su corrección, completitud y relevancia para el objetivo de la organización.

17) AJUSTE DE PRÁCTICAS

Como resultado del pilotaje se obtendrán puntos de mejora o ajuste a las prácticas definidas. Una vez ajustadas se establecen como línea base del proceso.

18) DESPLIEGUE DE PRÁCTICAS

El despliegue de prácticas estará a cargo de los equipos de mejoramiento quienes establecerán, también, la forma en que serán incorporadas al quehacer de la organización, preferiblemente en nuevos proyectos o en fases próximas a iniciar en proyectos existentes, si es que la utilización de la práctica no traumatiza los compromisos adquiridos en el proyecto con los stakeholders.

19) OBTENCIÓN DE EVIDENCIAS

Durante la utilización de las prácticas debe mantenerse un levantamiento de evidencias tendiente a generar la Base de Datos de los Indicadores de Implementación de Proceso (PIIDB) sobre la que, posteriormente, se apoyará la evaluación SCAMPI que valorará oficialmente a la organización en el nivel CMMi® seleccionado.

BIBLIOGRAFÍA






Documents

Proyecto y administración de proyectos · PDF fileProyecto y administración de proyectos Antes de involucrarnos en el apasionante tema de la administración de proyectos, es necesario