Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Humor del Líder

Problemas de comunicación
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
Artículos
 

¿Está en crisis la administración de proyectos a causa de las metodologías ágiles?

Por Norberto Figuerola [ Acerca del autor]

De acuerdo a observaciones realizadas por el autor de este artículo, debo admitir que la nueva certificación PMI® Agile Certified Practitioner (PMI-ACP®) despertó en mí, así como en muchos otros colegas algunas dudas. Esto me motivó a leer muchos encarnizados debates entre agilistas y tradicionalistas que confieso volvieron a despertar mis inquietudes sobre un replanteo en la profesión. El artículo publicado por Ken Schwaber en su propio blog y los comentarios recibidos me resultó impactante. Ya he visto además muchos informes que directa o indirectamente colocan en discusión o traen dudas sobre el objetivo que debe cumplir un gerente de proyecto. Tratando de colocarme en una posición totalmente imparcial, comento en este artículo ciertas apreciaciones sobre cómo veo la evolución de esta disciplina.

Project Management y Agile

La aparición y adopción constante de métodos ágiles para manejar proyectos, a mi criterio ha puesto en jaque la función e incluso el alcance del rol del gerente de proyecto. “No necesitamos ningún director de proyecto”, es una frase común que se escucha a veces por parte de los desarrolladores de software (me refiero a los que utilizan métodos ágiles). Consideran que los jefes de proyecto interrumpen el camino y sólo sirven como “secretarios administrativos” que no agregan valor. Cuesta explicarles educándolos sobre las ventajas típicas de un buen director de proyecto, cuando se trata de proyectos tradicionales, sin duda, un eficaz gerente de proyecto añade un valor agregado fundamental en todo el proyecto, logrando una mejora de la previsibilidad, la percepción y la probabilidad de éxito. Pero ¿francamente puede decirse lo mismo de proyectos ágiles o más pequeños y menos rigurosos? O ¿existe un conjunto diferente de habilidades y/o papeles necesarios para los mismos?

La naturaleza de los proyectos ágiles hace que el costo y el tiempo queden por lo general fijos en forma de “timeboxing” a través de cada iteración. Estas metodologías pueden ser utilizadas sólo en cierto tipo específico de proyectos: los proyectos de desarrollo de software en los cuales los equipos de recursos humanos son pequeños, altamente calificados, co-localizados y en contacto constante con el cliente.

También se supone que el nivel de criticidad es relativamente bajo, por lo que hay una alta tolerancia para la elaboración progresiva de los resultados. Por lo tanto para una organización y un equipo que están preparados para aceptar este planteamiento, puede ser muy eficiente el uso de estas metodologías ágiles. Teniendo en cuenta estos supuestos, parece que un director de proyecto experimentado y acostumbrado a la gestión de grandes iniciativas, estaría mal equipado para agregar valor a los proyectos ágiles. De hecho, sería como si un chef de un restaurante de altísima cocina fuera requerido para gestionar las actividades de un establecimiento de comida rápida. Probablemente el pobre chef agregue poco valor en esas circunstancias, lo que no quiere decir que un sistema de comida rápida no sea eficiente o no proporcione la satisfacción del cliente. En este tipo de proyectos las claves son:

Las líneas de base son irrelevantes: en un proyecto ágil, una línea de base no significa nada. El cronograma y el presupuesto se fija en cada iteración como “timeboxing”. Los requisitos de software van evolucionando a medida que el proyecto se desarrolla, por lo que no sería muy necesario el seguimiento del proyecto medido contra de la línea de base, ya que es un blanco móvil. En estos proyectos la comunicación y colaboración entre los desarrolladores de software y el cliente son los que garantizan el éxito.

Los requisitos formales no son de mucha aplicación: en los proyectos ágiles, los requisitos de alto nivel son capturados de forma anticipada, y los detalles se aclaran con cada iteración, justo antes del desarrollo de la funcionalidad. La idea es que se sabe mucho menos al comienzo por lo que sería una pérdida de tiempo formalizar requerimientos cuando todo va a cambiar. Además, las necesidades se recogen y se discuten en un marco de colaboración con todas las partes presentes para minimizar los errores de comunicación, lo que implica una participación muy activa del cliente.

Se requiere de más entendimiento técnico: en un proyecto grande y tradicional, el gerente del proyecto no necesariamente tiene que ser un experto en los detalles finos del proyecto, pero debe entender el objetivo, las necesidades, los problemas y los riesgos. Un proyecto ágil, por otra parte, exige que todos en el equipo entiendan los detalles e interconexiones técnicas involucradas. La experiencia sobre la industria es muy importante en este tipo de proyectos.

Los equipos son colaborativos y auto-organizados: como se mencionó, un equipo en un proyecto ágil suele ser auto-dirigido y co-localizado, y está en contacto permanente con los otros miembros. Esto incluye el cliente, los desarrolladores, administradores de recursos necesarios para garantizar un producto de trabajo que satisfaga las necesidades de los clientes. Esto significa que no hay un foco a una estructura centrada en el project manager, porque se habla más de colaboración y comunicación entre todos los miembros. Estamos hablando de equipos altamente calificados con experiencia previa y gran interacción con el cliente. En estos casos el riesgo tiende a ser menor y se convierte en un debate de colaboración, en lugar de ser una entidad independiente gestionada por un gerente del proyecto.

Si nos fijamos en Scrum (que es la metodología ágil más conocida y está aumentando en popularidad en los círculos de desarrollo de software), el “Scrum Master” y el “Product Owner” trabajan en conjunto para realizar la mayoría de las funciones que un gerente de proyecto habría hecho normalmente. El Scrum Master actúa como un facilitador para la eliminación de barreras y problemas del equipo, asegurando que utilicen productivamente la metodología Scrum y la comunicación constante con el Product Owner. Este último, a su vez, garantiza que las características y requerimientos levantados durante el proyecto se prioricen y sean entendidos. La funcionalidad se define a través de “historias”, que identifican al usuario, la acción y su beneficio para la función. Juntos, estos roles y el resto del equipo trabajan para completar lo que ha sido establecido en forma fija por cada iteración, llamada “sprint”.

Teniendo en cuenta esto, no hay mucho que pueda añadir un director de proyecto en este esquema y que no haya sido realizada por los roles mencionados anteriormente. ¿Qué lugar ocuparía un líder de proyectos en estos ámbitos?, en realidad no mucho. En este tipo de proyectos un gerente de proyecto podría actuar por ejemplo como el Scrum Master, ayudar a coordinar actividades y facilitar la metodología. También en este tipo de ambientes podría resultar muy útil la participación de un gerente de proyecto como especialista o analista del negocio y como negociador entre el cliente y los desarrolladores. Pero con todo, la función que cumpliría no debe confundirse con la típica de un gerente de proyecto tradicional. La verdad es que en un enfoque ágil no se utilizan todas las prácticas de gestión de proyecto y las funciones se comparten entre varias personas.

Todos sabemos que la mayor parte de las compañías en todo el mundo durante estos últimos 50 años ha venido cambiando la forma de ver la importancia del Project Management, y la necesidad de contar entre sus cuadros con la visión estratégica y habilidades de un gerente de proyecto. Sin embargo, últimamente y en algunos casos sobre todo, volvemos a la necesidad de “vender” el valor agregado del gerente de proyecto y de una metodología de gestión efectiva y eficiente de los mismos. Esto debido a que la tasa de fallos en los proyectos sigue siendo aún alta, y esto hace que dicha necesidad tenga que volver a explicarse a ciertos niveles y cueste cada vez más encontrarle una explicación satisfactoria. La verdad es que no todos creen en el “Project Management” o mejor dicho, no creen en su real utilidad. Algunos opinan que los gerentes de proyecto son simples burócratas, que insisten con el papeleo y con inútiles procesos que nada tienen que ver con el mundo real y peor aún, que no aportan valor. Cuando revisamos los problemas de fracasos en los proyectos, no es precisamente el gerente de proyecto o la metodología los factores causantes más importantes de dichos fracasos. Es cierto que hay gerentes de proyectos más capaces y con más experiencia que otros.

Del mismo modo, podríamos decir que existen metodologías o prácticas más maduras que otras, pero esto, debemos reconocerlo, no nos brinda hoy en día la confianza de que su utilización sea una certificación de éxito. Es por eso que está ganando en popularidad la difusión de nuevas metodologías, siendo las ágiles las que consiguen una adopción cada vez más progresiva. En mi opinión este tipo de metodologías traen resultados prácticos y exitosos en determinados procesos de desarrollo de software. Pero de ahí a generalizar como hacen algunos fanáticos ágiles, diciendo que cualquier tipo de proyecto (e incluyo en esto algunos proyectos de IT) deben ser gestionados bajo el amparo del Manifiesto Agile, creo que hay mucha diferencia. Sin embargo, de lo que si estoy seguro, es que vivimos en una era de cambios radicales, innovadores y de fuerte impacto. Por eso para los otros que siguen subidos al pedestal del Project Management tradicional, es necesario de una advertencia para que vean mejor la realidad.

¿Es suficiente el PMBOK®?

Nadie puede dar garantías de que cualquier tipo de proyecto, en cualquier industria, sea exitoso. En forma intuitiva podríamos afirmar que el éxito depende de varias circunstancias y factores, y en todos los casos como factor común está el talento y experiencia del gerente de proyecto, una buena planificación, el uso adecuado de una correcta metodología y tecnología, y el armado del grupo de trabajo ideal. Los procesos de gestión de proyectos de cualquier metodología deberían poder escalarse basados en el tamaño y complejidad del mismo. Si colocamos demasiados procesos de gestión en un proyecto pequeño estaríamos cometiendo el mismo error que si no aplicamos todos los adecuados y debidos procesos en los proyectos más complejos o grandes. El factor fundamental siempre pasa por el “valor” que como buenos gerentes de proyecto deberíamos agregar al mismo, sabiendo cuando utilizar o no, determinados procesos.

Algunos suponen que un buen gerente de proyecto puede ser exitoso en cualquier proyecto, independientemente de si tiene experiencia práctica sobre el área o no. Otros consideran que no se puede manejar un proyecto si no se cuenta con la experiencia sobre el área adecuada. Novatos líderes de proyecto por ingenuidad y en su afán de lograr la más prestigiosa credencial del Project Management Institute (PMI®), que sigue figurando entre las 10 primeras certificaciones mundiales, el PMP®, suponen que el conocimiento de todos los procesos de la Guía PMBOK® es todo y lo suficiente que debe conocer un gerente de proyecto. El mismo PMI® indica que el PMBOK® es sólo una parte del cuerpo total de conocimientos de esta disciplina, y más que una metodología se trata de una colección de buenas prácticas.

La tercera edición (anterior) de esta Guía mostraba un gráfico sobre todo lo que comprendía un cuerpo de conocimientos sobre Project Management, e incluía: conocimiento sobre la “Guía PMBOK®”, “Las Habilidades Interpersonales”, “Las Habilidades y conocimientos generales de Management”, “Entendimiento del ambiente del proyecto” y “Comprensión del Área de Aplicación, estándares y regulaciones (industria)”. En resumen, no se puede manejar un proyecto, o no se es un buen profesional si el practicante no cuenta con un entendimiento suficiente no sólo de “una metodología” como el PMBOK®, sino además cómo aportar valor en las otras cuatro áreas de competencias mencionadas, y las mismas no pueden ni son explicadas en los cursos generales de Project Management o incluso no son evaluadas en los exámenes de certificación.

Cómo se fue transformando el Project Management

En las últimas décadas las organizaciones han tratado de modificar sus estructuras tradicionalmente funcionales en algo más efectivo para adaptarse a los acelerados cambios tecnológicos y sociales, tratando de ser más eficientes para cumplir las demandas del mercado. La consecuencia de esto fue la evolución de una organización funcional en lo que se denomina una organización matricial, que tratando de mantener su estructura funcional permita la formación temporaria de equipos de proyectos cross-funcionales, organizados y controlados por la figura de un gerente de proyecto. Sin embargo y dado que las soluciones “a medida” se transformaron en la norma, incluso las organizaciones matriciales pasaron de moda. Algunos autores señalan la evolución de las organizaciones en “adaptativas”, aquellas que van transformándose de acuerdo a las exigentes complejidades y cambios del mercado y exhiben comportamientos de auto-organización en sus equipos de trabajo. Esta misma evolución se plasmó en los estilos de liderazgo, pasando de un tradicional jerárquico o “top down” a estilos más participativos, democráticos e inclusive a estilos “facilitadores” en donde el rol del líder es simplemente eliminar los obstáculos a un grupo de trabajo auto-disciplinado, auto-organizado y competente.

Podríamos también simplificar diciendo que dicha evolución se manifiesta en el Project Management: en un primer momento, el Project Management era visto como una sub-disciplina de la Ingeniería, de hecho se aplicaba exclusivamente en proyectos de construcción, ingeniería y defensa únicamente (organizaciones totalmente proyectizadas). Los libros trataban sobre las técnicas, herramientas y métodos cuantitativos de gestión efectiva de procesos. Por ese entonces el concepto de Management era muy claro: dirección y control, mucha planificación y algo de motivación. Para Frederick Winslow Taylor, “El trabajo consistía principalmente en tareas simples, no particularmente interesantes. La única manera de conseguir que la gente consiga hacer su trabajo bien, es incentivarla adecuadamente y controlarlos muy de cerca”.

El Management fue evolucionando a la par de los avances tecnológicos, sociológicos y de comunicación fortalecidos por las interacciones sociales a través de internet. Ya no sólo es importante el Management para la gestión, sino que lo es mucho más el Liderazgo, el concepto de Equipo. El proyecto no es otra cosa que manejar gente. Es todo acerca de la gente que hace el trabajo en equipo y cómo se interactúa con ellos, esto podría verse como una segunda fase de evolución del Project Management. Si se fijan, todos los libros de Project Management cambiaron el foco de las habilidades “duras” hacia cómo deberíamos ser expertos en las denominadas “habilidades blandas”. Cualquier organización, asociación, grupo de interés o foro sobre Project Management comenzó a escribir artículos sobre las distintas habilidades interpersonales, dado que no había mucho más que agregar a temas como Diagramas de Gantt, Camino Critico, Curva S, etc.

La tercera fase evolutiva surgiría del hecho de reconocer que aún poniendo las más adecuadas herramientas y técnicas y sumarle un liderazgo democrático con profundas interrelaciones humanas pareciera que no es suficiente para el éxito de algunos proyectos. A principios del 2001 el Manifiesto Ágil sentó las bases para otro tipo de gestión de proyectos orientado al desarrollo de software que prometía bajar la tasa de fracasos. De hecho en cierta forma lo logró y esto puso en jaque a los planteos tradicionales, dado que “la metodología ágil” no trajo conceptos o procesos más complicados, sino todo lo contrario. Pero deberíamos ser concretos sobre cómo y dónde tuvo y tiene éxito este tipo de aproximación. El concepto de liderazgo en estos métodos coincide con el ya visto de “facilitador” y surgen nuevas expresiones como el “servant leader” donde la figura de un gerente de proyecto está totalmente diluída. El desarrollo ágil fue producto de las compañías que desarrollaban software, principalmente en internet. Su éxito fue contundente y el intento de replicar estos métodos de empresas de software en corporaciones mayores no significa que se vaya a repetir. El modelo de trabajo que proponen estos métodos requiere de un trabajo muy estrecho entre cliente (gerente de producto) y equipo de trabajo y conseguir este tipo de involucración en determinado tipo de empresas es imposible. Es muy importante hacer énfasis en la diferencia que existe entre “Product Management” y “Project Management”.

Product Management vs Project Management

Actualmente grandes empresas tecnológicas, de internet o desarrollo web siguen definiendo la figura del “product manager” incluyendo en él funciones del “project manager”, tal el caso de Microsoft, Google, Yahoo, YouTube, etc. Es muy común que este tipo de empresas como otras de Internet o Casas de Software tengan gerentes de producto. ¿Cuál es la diferencia entre este rol y el de gerente de proyecto? En realidad es un poco semejante a la diferencia que existe entre un rol estratégico y un rol de ejecución. Los conceptos pueden resultar similares, los dos son gerentes que tratan de asegurar el buen cumplimiento de un proyecto, probablemente con conocimientos y habilidades similares, sin embargo existen grandes diferencias entre un product manager y un project manager, y confundirlos puede traer problemas. El gerente de proyecto es responsable por el éxito en la “entrega” de un proyecto (emprendimiento único con principio y fin) conforme al tiempo, presupuesto, metas, alcance y otras restricciones. Coordina recursos, lidera y controla, gestiona problemas y riesgos y coordina todos los elementos necesarios para cumplir con el proyecto, sus objetivos y la satisfacción del cliente. El product manager se refiere a la coordinación de todos los aspectos de la creación y gestión de un producto. El proyecto puede encararse para construír un producto, agregar más funcionalidad a uno existente, o crear nuevas versiones del mismo, pero cuando el proyecto está completo, el gerente de proyecto terminó su labor y por lo general se ocupará de otro proyecto y probablemente también de otro producto. En cambio, el gerente de producto no se transfiere, permanece como responsable de dicho producto durante todo su ciclo de vida.

El ciclo de vida de un gerente de proyecto, es el proyecto mismo, el ciclo de vida de un gerente de producto es el ciclo de vida total del producto hasta su muerte o reemplazo. Ambos roles pueden trabajar en conjunto, pero mientras el gerente de producto querrá agregar más funcionalidades y desarrollará estrategias para modificaciones y mejoras constantes, el gerente de proyecto tratará de mantener el alcance acotado para que el proyecto pueda cumplirse conforme al plazo y presupuesto. De existir ambos roles y ser ambos expertos, sabrán convivir y crear un balance adecuado de dicho conflicto. Un buen gerente de proyecto sabe que el éxito no es solo el cumplimiento del proyecto en tiempo y presupuesto, sino además lograr los objetivos del mismo. Del mismo modo un buen gerente de producto sabe que los cambios pueden llegar a ser infinitos en búsqueda de la perfección y que demorar la entrega o salida al mercado tiene un precio.

Este tipo de roles como vimos es muy común en empresas de software. Las metodologías ágiles nacidas en estos ambientes se basan más en la función de un gerente de producto que la de un gerente de proyecto. No interesa tanto el control del alcance sino la funcionalidad del producto. Existen diferentes tipos de aproximación de metodologías ágiles, pero en casi todos los casos el alcance de la gestión ágil es más bien a nivel técnico, en el desarrollo de software, no existe una clara definición del rol de gerente de proyecto, más bien cuando se llega al nivel del product manager, se hace recaer sobre el mismo algunas tareas de un project leader.

Si se selecciona una metodología ágil, la misma debe siempre de estar de acuerdo a la lógica y cultura de la empresa y ajustarse al negocio, sin entrar a discutir con los puristas sobre si efectuamos cambios, adaptaciones o inclusive si combinamos distintas aproximaciones entonces dejaría de ser ágil. De todas formas siempre que trabajemos con estas metodologías el rol del gerente de proyecto cambia, se hacen mucho más importantes conceptos más técnicos y otra forma de trabajo y gestión, donde ya un cuerpo de conocimiento como la Guía PMBOK® pierde algo de sentido. Igualmente y tal como se mencionó anteriormente, el cuerpo de conocimientos sobre Project Management no sólo lo conforma un BOK, sino además el conocimiento sobre la industria, estándares y avances, y en este sentido en el ámbito de IT, es sin duda cierto que para algunos proyectos el uso de dichas metodologías ágiles es ideal. Mi duda es ¿por qué el PMI® se ocupa recién ahora en hablar de ello e incluso hasta dedicarle una nueva certificación?. ¿El manejo de proyectos en construcción, farmacéuticos u otras industrias pueden seguir aproximaciones ágiles? Si admitimos que no, ¿por qué no sería razonable además que el PMI® dedique alguna certificación para dichas industrias? Personalmente creo que la respuesta a esto es moda….y dinero.

Buenas Prácticas en Project Management

Hoy en día podemos generalizar que los proyectos han crecido en complejidad y que es muy común que los gerentes de proyecto se encuentren en dificultades para llevar en forma eficiente su trabajo. Reconociendo estos desafíos, dificultades, cambios y avances tecnológicos, los gerentes de proyecto tratan de utilizar los estándares que mejor puedan cumplir con los objetivos de éxito y entrega de los mismos. A esto deberíamos sumarle el hecho de que actualmente el trabajo en equipo y el trabajo en sí mismo son diferentes que hace 50 años antes. Como se mencionó en el artículo “El Dinero no es un factor motivador”, el trabajo hoy en día es más bien de tipo “heurístico”, creativo, se aplica más conocimiento e innovación, los equipos requieren de más autonomía para ello. Teniendo en cuenta la evolución marcada en párrafos anteriores sobre Liderazgo y Project Management, la pregunta sería ¿cuáles son los mejores estándares hoy en día? Francamente no existe una respuesta directa dada la gran variedad de proyectos y ambientes. La Guía PMBOK® sin duda alguna, sigue siendo uno de los más reconocidos mundialmente. Otro ampliamente usado es el de la OGC PRINCE2®, y a estos dos podríamos agregarle el del International Project Management Association (IPMA). Algunos autores sugieren que para la profesión una combinación del énfasis en las habilidades interpersonales que tiene el IPMA, sumado al énfasis de los procesos del PMI® podrían dar una buena sinergía a la disciplina del Project Management. De un relevamiento general el uso de una metodología está mucho más repartido y además de estos tres clásicos métodos, las organizaciones hoy en día utilizan otras aproximaciones como ser :

  • Nuestra propia metodología corporativa (muy utilizada por grandes empresas)
  • Agile Project Management
  • Critical Chain Project Management
  • Una combinación de diferentes metodologías
  • Lean Thinking / Kanban process Project Management

En mucha literatura referida a aproximaciones de gestión de proyecto adaptativas y ágiles se hace también mención al pensamiento Lean y a Kanban asociándolos con métodos ágiles. El pensamiento Lean y Kanban son filosofías anteriores al movimiento ágil que sin embargo demuestran que pueden convivir y nutrirse perfectamente. Muchos conceptos sobre el pensamiento Lean (value stream mapping, wip limit, cycle time, etc) han sido incluídos en la nueva certificación del PMI-ACP®. Actualmente para el que no está informado ya existe el LSSC siglas del Lean Software and Systems Consortium que cuenta no sólo con su propio BOK sino además sería la tercera certificación oficial que existe en “métodos ágiles” luego de Scrum y DSDM. Por otro lado Kanban está ganando popularidad en los círculos de project management, fundamentalmente en lo relacionado con la visualización de workflow, mejores reportes, limitación del work in progress y balance del trabajo.

La mejor práctica sigue siendo la que le brinde a una empresa particular los mejores resultados, más allá de las certificaciones profesionales. Y esto depende mucho del tipo de industria, sector de negocio, región geográfica, complejidad y tamaño del proyecto, etc. Podriamos decir que existen dos tipos de conocimiento: explícito e implícito. El conocimiento explícito es aquel capturado, escrito y documentado que se puede encontrar en libros, manuales, políticas, procedimientos y BOK’s. El conocimiento tácito o implícito es el que existe en la mente de las personas y se transfiere mediante entrenamiento, trabajo, mentoring, coaching, conversaciones, discusiones y experiencias de gente experimentada y entrenada. Este conocimiento tácito que involucra ricas experiencias de distintas áreas de negocio, geográficas e industrias, es el que debería alimentar e ir transformando la Guía PMBOK®, para que no quede como un conjunto de procesos “ideales” de gestión de proyectos y bajarlos más a la realidad.

Conclusión

Para los que me conocen, saben acerca de mis opiniones críticas, replanteos y mi posición totalmente imparcial sobre distintos temas. Algunos por ahí me han oído despotricar sobre discrepancias que tengo con el PMI® o con gente que considero no ameritan la certificación PMP® en base a sus motivaciones (o conocimientos). Si en algún momento, obtener la certificación PMP® era la luz al final del túnel, hoy en día sería la luz al comienzo del mismo. Un profesional debe estar continuamente enriqueciéndose de los nuevos conceptos de gestión, management y calidad, tal como me esfuerzo en explicarlo permanentemente en mis cursos.

De hecho como fue referido por algunos autores, el Project Management es una profesión “accidental”, porque no existió una carrera en el pasado para su preparación. Personalmente como otros de mi generación y pertenecientes a distintas profesiones (marketing, ingeniería, finanzas, etc.) fueron inmersos en la gestión de proyectos (“task force” se llamaba antes en IBM cuando comencé a trabajar). Como no había o existía muy poco entrenamiento formal, las propias empresas preparaban a sus “gerentes”. Después de trabajar en algunos proyectos, se comenzaba a aprender cada vez más basado en la experiencia sobre la profesión.

El PMBOK® no es “todo” lo que hay que saber para ser gerente de proyecto, sino que es una excelente y muy completa Guía a utilizar como punto de partida para la carrera profesional. Representa un sub-conjunto de mejores prácticas del mercado que debe ser complementado y enriquecido con nuevas ideas, nuevos conceptos, nuevos métodos y técnicas y nuevas habilidades que debe manejar un gerente de proyecto. Con todo, la evolución y los cambios continúan y asi como la irrupción de los nuevos métodos ágiles han cambiado radicalmente el rol de un gerente de proyecto, nadie sabe cómo seguirá transformándose esta profesión, que asi como nació casi accidentalmente, pueda también ser transformada accidentalmente en algo muy diferente a lo que comúnmente estamos acostumbrados a conocer.


Esta página ha sido calificada como:
Califica esta página:   


+



Veronica Papandrea dijo el 05 Agosto de 2011:
Muy interesante el artìculo. Actualmente trabajo como PM en una Consultora de Software con Mètodos Agiles y me sentì completamente identificada con el artìculo. Creo que en estos entornos se resta importancia a la planificación, liderazgo y gestiòn del camino crìtico, que en mi opinion resultan necesarias en proyectos "llave en mano".

Norberto Figuerola dijo el 04 Agosto de 2011:
Fernando: disculpas por la redacción, mi intención fué volcar el resultado de la encuesta y donde dice "nuestra propia metodología" es la de cada corporación (ej: IBM).
Andrés: efectivamente, yo también estoy trabajando con proyectos en donde el core es tradicional pero se agregan matices de ágil (por supuesto es de IT)
Nora: gracias por tus comentarios
Mario: muchas gracias también por tus comentarios y efectivamente estamos en un mundo de cambios que se suceden exponencialmente, por lo que es muy importante estar al tanto de diversos temas.
Queda mi mail para cualquier información adicional que necesiten y pueden visitar además mi Blog Site.
Saludos cordiales.

Fernando Larrea Leoro dijo el 04 Agosto de 2011:
Excelente documento ! Sólo una aclaración, cuando se comenta sobre las metodologías utilizadas, el párrafo "Nuestra propia metodología" hace referencia a alguna que proponen ustedes ?
Muchas gracias.

Andrés Mora dijo el 04 Agosto de 2011:
Un articulo muy interesante, que sin ir mas allá y entrar en tecnicismo te da muy buenas sensaciones. Yo ahora estoy en un proyecto de Telecom y aunque se maneja la metodología tradicional tienes ciertos matices de metodologías ágiles. Muy buen aporte, gracias.

Nora dijo el 04 Agosto de 2011:
Muy interesantes comentarios. Muchas gracias por el aporte!!!

Mario Morales dijo el 03 Agosto de 2011:
Yo soy muy novato, en la gestión de proyectos, ya que estoy en el décimo ciclo de la carrera de Ingeniería Informática, pero artículos como el suyo me sirven para despertar mi curiosidad en nuevos temas. Muchas gracias por la excelente lectura.



Alcanzando el éxito del proyecto con los requerimientos (Jorge Victoria)
+
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. PMBOK, PMP, Project Management Professional, Project Management Professional (PMP), PgMP, Program Management Professional (PgMP), PMI-RMP, PMI Risk Management Professional (PMI-RMP), CAPM, Certified Associate in Project Management (CAPM), PMI-SP, PMI Scheduling Professional (PMI-SP), THE PMI TALENT TRIANGLE and the PMI REP Logo are registered marks of the Project Management Institute. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.