Ahora resulta que somos "todólogos"...

Llamale como quieras: Administración de Proyectos, Gestión de Proyectos, Dirección de Proyectos, etc. todos estos conceptos de alguna u otra manera te llevan a una definición común: Es la aplicación de conocimientos, habilidades, herramientas y técnicas a actividades del proyecto para cumplir con los requisitos del mismo.
¿Por qué comienzo así este post? Sencillamente, porque acabo de ver una oferta de trabajo para un supuesto "Administrador de Proyectos" cuya descripción de actividades a realizar no tienen que ver con la definición anterior. Permitanme transcribir dicha redacción:

Folio: 9999 - Administrador de Proyectos - Tiempo Completo
PRINCIPALES FUNCIONES: Administrar bases de datos SQL. Instalar equipos Servidores, clientes y Periféricos de Red. Configurar dispositivos de interconexión. Instalar y operar software para administración redes. Configurar el hardware y software administrativo de red. Administrar los recursos de red. Administrar archivos, documentos y licencias. Instalar hardware de seguridad. Instalar software de seguridad. Administrar los recursos de seguridad. REQUISITOS Mínimo de 2 años en call centers. Bases de datos SQL. Administración de marcador predictivo, IVR y configuración de campañas. Conocimientos de PHP, Crystal Reports, AJAX, JAVA, HTML.

El anterior anuncio apareció en una prestigiada bolsa de trabajo en mi país (México) el día de hoy, y no pude resistirme a la tentación de comentar al respecto.
Una de dos: o la compañía que publicó este anuncio no tiene ni la más mínima idea de a qué nos dedicamos los Administradores de Proyectos o la profesión se ha devaluado a tal punto que ahora no solo tenemos que responder por las comunicaciones dentro del proyecto, el presupuesto, el cumplimiento del alcance en tiempo y calidad, lidiar con los riesgos y mantener al equipo de trabajo motivado, sino que además hay que hacerla de programador, administrador de bases de datos, técnico en redes, técnico y administrador de equipos electrónicos para "customer care", etc., etc., etc. Me imagino que un diálogo común en esa compañía sería: "Que tal, soy el administrador del proyecto, también vengo a analizar el problema de negocio y a evaluar qué solución técnica es la mejor, además voy a definir la arquitectura y a programar la solución y a hacer las pruebas de calidad, finalmente voy a revisar que la topología de la red sea la correcta y a revisar sus equipos del call center para que todo esté funcionando correctamente. Por último y si el tiempo lo permite, optimizaré cualquier aspecto de los entregables como la base de datos, los elementos de la red y cualquier interfaz que hubiera entre todos estos equipos tecnológicos. Por favor firme este 'Project Charter' en donde se establece que yo tengo la autoridad de hacer todo esto."
Si, desde luego que estoy siendo irónico (aunque no es mi estilo ni el tono que quiero manejar en este blog). Quiero pensar que a quienes publicaron este anuncio se les revolvió la descripción del puesto con el título y no que están tratando de "vender" una posición con un nombre interesante pero con actividades muy distantes a lo que el título hace referencia.
Puedo imaginar que quien publicó el anuncio debe ser una compañía pequeña en la que contratan a un individuo para hacer una multitud de funciones y en la que no queda claro quién es responsable de qué ni a quien tienen que reportar los avances, logros y fallas. Finalmente, muchas de las actividades descritas en esta oferta laboral no tienen que ver con proyectos sino con operaciones continuas y eso va en contra de la definición de un proyecto (ver posts de marzo y julio acerca de la definición de Proyecto).
En fin, espero que las organizaciones en México y en general en todo el mundo sepan llamar las cosas por su nombre antes de hacer el ridículo públicamente con este tipo de anuncios.
Hasta la próxima.

Fernando Valdez, PMP
[LAP]

Proyecto definido (2da parte)

Que tal,
Continuando y terminando con esta serie de 2 posts en los que estoy definiendo y comentando un Proyecto, ahora es el momento de cubrir la segunda parte de la definición de proyecto, aquella que habla del alcance.
Como comentamos, un proyecto se lleva a cabo con el objetivo de crear un producto, servicio o resultado único.
Esto quiere decir que un proyecto sirve para crear algo que no existe y que cuando se alcance ese objetivo se dará por terminado el esfuerzo del equipo de proyecto. Otra característica que incluye esta segunda parte de la definición es que el producto del proyecto debe ser único, es decir, es algo que se crea y que nunca antes había existido con esas características específicas como dimensiones, utilidad, etc.
Para aterrizar el ejemplo, hacer un auto en una línea de producción no sería un proyecto dado que se elaboran muchos autos por hora con las mismas características, pero diseñar un modelo de un auto que vaya a tener características nuevas o en una nueva distribución, eso si sería un proyecto.
En un proyecto es necesario definir clara y exhaustivamente el alcance de lo que se va a crear, de lo contrario se incurrirá en la creación de cosas que no fueron solicitadas o se omitirá la creación de cosas que debieron crearse. Una pobre definición del alcance también puede impactar en crear los entregables con especificaciones diferentes a lo solicitado.

Existen proyectos en los que es necesario crear estructuras, máquinas, instalaciones, herramientas, etc. que serán de utilidad para crear el componente final.

Esto se da mucho en la industria de la construcción (no solo en esta industria). En días pasados estuve observando en Discovery Channel un programa en el que estaban haciendo una estructura conformada por túneles bajo tierra y un puente colgante que comunicarían dos países europeos que estaban separados por un canal de agua. Los túneles debían permitir el paso de automóviles y trenes en ambos sentidos y un canal extra para emergencias. El problema es que no existe ninguna fabrica en el mundo que construya este tipo de estructuras de cemento y acero, de tal forma que dentro del alcance del proyecto se incluyó hacer una fábrica de trozos de túnel a la orilla del mar para facilitar el transporte de esas piezas que pesaban unos cuantos millones que kilogramos. Cuando se construyeron las secciones necesarias y estas fueron instaladas y probadas, la fábrica dejó de existir.

El alcance de un proyecto debe ser claramente definido, pero también debe incluir artefactos intermedios si es el caso. Una vez definido todo el alcance, entonces se dispara el resto de las estimaciones de tiempo, costo, recursos necesarios, contrataciones y compras necesarias, comunicaciones necesarias, evaluación de riesgos, etc.

Espero que esto complete la información necesaria para definir un proyecto.
Quizás un poco tarde, pero en siguientes posts voy a hablar de las diferencias que hay entre el PMBOK 3ra edición y la 4ta edición (para aquellos interesados en presentar el examen para PMP 4ta edición con información de la 3ra).
Hasta pronto.

Fernando Valdez, PMP
[LAP]

Proyecto definido

En mi opinión el concepto más importante acerca de Project Management es la definición de Proyecto. Aunque muchos opinarán que es obvia la necesidad de conocer esa definición, en muchas ocasiones el verdadero espíritu de esta definición es pasada por alto durante un proyecto.

Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.

Como se puede ver, esta definición tiene dos partes principales: aquella que habla del tiempo y aquella que habla del alcance.
1.- Un proyecto es un esfuerzo temporal significa que en algún momento se podrá identificar tanto el inicio del proyecto como el fin del mismo. Un proyecto no es un esfuerzo infinito como lo puede ser una línea de producción.
2.- Por otro lado, un proyecto se lleva a cabo con el objetivo de crear un producto, servicio o resultado único. Aquí se está hablando del alcance del proyecto y de las características que tendrá ese producto, servicio o resultado.

En este post quiero comentar acerca del tiempo.
Una de las restricciones mas comunes de un proyecto es el tiempo. Hay algunas organizaciones en que es la única restricción (los proyectos los ejecuta personal pagado bajo la nómina y con recursos ya adquiridos).
Que un proyecto sea un esfuerzo Temporal significa que tiene inicio y fin definidos, no importando si estas fechas están cercanas (proyectos cortos) o muy separadas (proyecto largo). No importa si la fecha de inicio es hoy o será dentro de un año. Lo que yo considero mas importante hablando del tiempo, es que en algún momento ese esfuerzo se terminará, lo que significa que los integrantes del equipo serán liberados para ser asignados a otras actividades, el producto entrará en operación (si es el caso), los documentos del proyecto deberán ser almacenados y los centros de costo del proyecto serán cerrados (si así lo amerita). En resumen, el proyecto ya no existirá pero habrá servido para crear un producto, servicio o resultado.
Cuando hablamos de algunas otras restricciones en el proyecto como el presupuesto, nos enfrentamos a restricciones importantes pero que pueden ser manipuladas para ajustarse al desempeño del proyecto: podemos aumentar o disminuir el presupuesto. Otras restricciones como la calidad del producto final también pueden ser manipuladas aceptando mayor o menor nivel de calidad en alguna de las características del producto final o cambiando el número de características con las que debe cumplir el producto final. Pero el tiempo es una restricción difícil de manipular. Si, ya sé que están pensando "pero el tiempo también lo podemos manipular moviendo las fechas de entrega"... efectivamente, podemos mover las fechas de entrega, pero no podemos incrementar el número de horas que hay en un día o detener el reloj para terminar en la fecha pactada originalmente. Quizás lo anterior suene obvio, pero piensalo un momento... este es el tipo de restricciones que impactan de una mayor manera al proyecto.
Muchos Project Managers tratan de administrar el tiempo en un proyecto siendo que es algo que no se puede administrar (no he sabido de nadie que haya agregado 10 minutos más a cada hora del día), pero lo que si podemos administrar es el resto de las variables para ajustarnos a las fechas de entrega. Podemos agregar recursos al proyecto, aumentar el presupuesto, administrar a la gente en el seguimiento de issues, etc.
Cualquiera que sea el caso, en algún momento el proyecto llegará a su fin, ya sea porque se completó con los objetivos del proyecto o porque fué cancelado. Tenemos una serie de variables dentro del proyecto que deberemos administrar adecuadamente para que cuando llegue el tiempo del fin del proyecto, podamos entregar el producto final con todas sus características y dentro de las especificaciones solicitadas.
En el siguiente post cubriré el segundo aspecto de la definición de proyecto: el alcance.
Saludos!

Fernando Valdez
[LAP]

Vientos de cambio

Que tal,
Dado que las necesidades de nuestros lectores han ido cambiando (y las mías también), voy a cambiar un poco el formato de estos posts.
Normalmente publico Lecciones APrendidas que obtengo durante mi gestión com PM (Project Manager / People Manager) y procuro hacerlo al menos una vez al mes. Sin embargo tenemos algunos lectores que están por presentar su exámen de certificación para convertirse en PMP y estos tienen necesidades diferentes.
Definitivamente no voy a convertir este blog en un sitio de conceptos del PMBOK, pero voy a tratar de alternar una Leccion APrendida y alguna capsula teórica, una recomendación o una mejor práctica (best practice). Estas últimas serán recopilaciones de mi experiencia, pero en un formato mucho mas breve.
Espero que el cambio les agrade y me permita aumentar la frecuencia de publicaciones que hoy en día está muy (muy muy) espaciada.
Buen día y ¡Saludos!

Fernando Valdez, PMP

Seguimiento...

No estoy seguro si en otras versiones del idioma español se diga "seguimiento" a la acción de verificar que un plan se esté ejecutando de acuerdo con lo previsto en términos de tiempo y compromisos (amigos de Argentina, España, Costa Rica y demás países de habla hispana, ayudenme aquí), pero la idea central de el título de este post es hacer referencia a una de las razones por las que muchos proyectos fallan.
En mi experiencia como Project Manager me he dado cuenta de que en algunas empresas el seguimiento que se le da a los compromisos en muchas ocasiones es informal y en otras es mucho mas formal.
Recuerdo haber participado en reuniones de definición de requerimientos en una compañía en las que se decía mucho, se apuntaba poco y se le daba seguimiento solo a aquello que realmente se había convertido en un problema urgente. En ocasiones se hacían minutas de la junta y ya. En otras ocasiones, al pasar de las semanas desaparecía el envío de minutas y se cancelaban las reuniones de seguimiento. Cuando surgía una situación de mayor prioridad, el asunto original se olvidaba y se desviaba la atención hacia el problema urgente, pero no se documenta formalmente hasta dónde se llegó o por cuanto tiempo se estará suspendiendo el primer asunto, ni se definía con qué nueva frecuencia se dará seguimiento a ese proyecto.

Tuve una experiencia en un proyecto con una compañía de USA en la que organicé una reunión diaria de avances (30 minutos de duración) dado que se había puesto en producción un sistema que aún presentaba algunos problemas funcionales. A la reunión asistían un VP (Vice-Presidente) dos directores y dos gerentes. Me correspondía el "honor" de organizar la reunión y comunicar los avances que se habían logrado en las 24 horas anteriores a la reunión.

Debo confesar que durante ese mes y medio que duró esa reunión diaria no fuí el Project Manager más feliz de la compañía.

En cada reunión iniciabamos puntualmente y revisabamos los pendientes discutidos en la reunión anterior y su status actual. Continuábamos tomando nuevas decisiones sobre esos pendientes aún abiertos y se solicitaba a los usuarios cerrar los pedientes que habían llegado a conclusión. Luego se trataban los nuevos problemas detectados y su status. El grupo priorizaba su orden de atención y por último se comentaban asuntos generales como días inhábiles en este o aquel país.

Durante mes y medio administré esa reunión que en ocasiones era asaltada por un solo tema de mayor importancia (afectaciones masivas a usuarios, etc.).

Después de cada reunión me correspondía registrar cualquier cosa nueva que no estuviera en nuestro resumen de pendientes (normalmente uso una hoja de MSExcel para esto) y continuaba alineando a los diferentes equipos hacia alcanzar los objetivos. El resto del tiempo antes de la siguiente junta los miembros del equipo avanzaban en su trabajo, nos comunicabamos para comentar cualquier problema, envíabamos correos y todo era en relación a lo comentado en la reunión de ese día. A veces tomábamos decisiones acerca de mantener algunos miembros del equipo trabajando por horas extra para poder entregar un status mas favorable en alguno de los asuntos prioritarios en la siguiente reunión, etc.
Finalmente se llegaba la víspera de la siguiente reunión, me reunía con el equipo para revisar avances, problemas, riesgos, retrasos, etc. alimentaba mi hoja de pendientes y listo, a la reunión. Y volvía a empezar el ciclo.

Con el tiempo decidimos que esa reunión dejara de ser diaria y pasó a tener lugar tres veces a la semana, luego dos veces por semana y actualmente solo nos reunimos cada 15 días para comentar sobre la operación del sistema. Yo no coordino esa reunión porque mi puesto es Project Manager (un Proyecto tiene un inicio y un fin bien definidos, la operación del producto resultante le corresponde a un gerente de operaciones), pero aún sigo siendo invitado dado que en otro momento de la historia estuve ampliamente involucrado.

En fin, mi idea es compartir con Ustedes esta nueva experiencia que adquirí acerca del seguimiento de los proyectos.

No siempre es necesario sostener reuniones diarias, de hecho es un tanto excesivo, pero este caso lo ameritaba. Mi decisión por hacer esto es porque había mucho en juego y los ejecutivos querían asegurarse que todo estuviera siendo considerado. Normalmente se pueden tener reuniones de seguimiento con gerentes (managers) de manera semanal y con directores y VPs de manera mensual.

Para aquellos interesados en referencias al PMBOK, en este post se cubrí algunas actividades de Ejecución y Monitoreo del proyecto, por favor refiéranse a los procesos 4.4, 4.5, 8.3, 9.4, 10.2, 10.4, 11.6 para mas detalle en lo que se debe hacer (PMBOK 3ra edición).

Gracias por detenerse a leer este post, les envío un caluroso saludo invernal (en el hemisferio norte, por supuesto). Saludos!

Fernando Valdez
[LAP]

Feliz año nuevo

Que tal,
En esta ocasión me dirijo a los lectores (que ya no han de ser muchos dada mi ausencia) para desearles un feliz año nuevo.
Dada mi última experiencia laboral, he entendido que existe una grán diversidad de razas, religiones, culturas, etc. y que en ocasiones es difícil hacer llegar un mensaje sin que estos factores (raza, cultura, religión, etc.) generen ruido en el mensaje. Habrá quienes celebren esta fecha (fin de año) y habrá quienes no lo hagan, pero lo que es universal y no tiene género, cultura, etc. es el sentimiento que se desea comunicar.
Dicho esto y para ponerlo en términos mas prácticos, sea que celebres año nuevo o no, mis deseos es que tengas felicidad y fuerzas renovadas en este año que comienza. Un año solo es una etapa de la vida, como en un proyecto. Al final de cada "etapa" es bueno hacer un "phase gate" en la que se pueda revisar el "desempeño" del equipo del proyecto, el desempeño del presupuesto, el desempeño del calendario (schedule), incluso es un buen tiempo para actualizar los indicadores de estos últimos dos (CPI (cost performance indicator) y SPI (schedule performance indicator) respectivamente).
Te invito a hacer una revisión de fin de fase de tu proyecto de vida y a ajustar los indicadores si es necesario. Los propósitos son el equivalente a los hitos (milestones) del proyecto, así que no olvides revisar qué tanto avance llevas y replantear aquellos que no parecen ser alcanzables.

Un propósito (hito) sin fecha de cumplimiento sólo es una buena intención.

Como sea, deseo que tengas un feliz año nuevo y que empieces 2009 excelentemente.
Por mi parte estaré tomando todo el tiempo posible para continuar esta comunicación y que mis dos lectores :) sepan que sigo vivo.
Saludos!
Fernando Valdez

Con criterio de Project Manager

El tiempo ha llegado en que el producto final de nuestro proyecto sea entregado al cliente, pero dado que experimentamos literalmente cientos de cambios en la definición y dado que nunca fue autorizado un cambio en la fecha de entrega, el producto final se redujo a contar con un porcentaje de la funcionalidad original.
Permítanme hacer un paréntesis con respecto a esto.

Hace tiempo, cuando trabajaba en otra compañía, acostumbraba bromear con los clientes acerca de los entregables y les decía: “Normalmente solo puedo satisfacer dos de las tres variables siguientes: Costo, Calidad y Tiempo… Si necesitas que el proyecto acabe rápido, probablemente tendremos que sacrificar la calidad y/o tendrás que pagar más. Si necesitas que salga rápido Y barato, entonces no tendrá mucha calidad. Si requieres que el producto tenga mucha calidad pero a bajo costo, entonces nos vamos a tardar en entregarlo”. Haz las combinaciones que quieras… aquellos que han trabajado en proyectos me podrán entender.
En Project Management se habla de la muy conocida triple restricción: Tiempo, Alcance y Presupuesto (o recursos). Comunmente encontramos un diagrama con un triángulo equilatero en el que cada una de las tres palabras (restricciones) se encuentran dibujadas en cada vértice del triángulo o en cada lado (como la imagen que anexo). La lectura a este diagrama es la siguiente: el Director del Proyecto debe asegurarse de que el cliente reciba todo lo que se prometió usando solamente el presupuesto establecido y dentro del tiempo estipulado al inicio del proyecto. En referencia al triángulo existe otra palabra, pero esta va al centro del mismo, y esa palabra es Calidad. Cualquier cambio en una de esas variables impacta a las otras y por ende a la calidad.
De tal forma que antes no estaba tan equivocado con mi broma de las tres variables, pero mi enfoque era incorrecto: si quieres ser un profesional deberas entregar todo dentro de las tres restricciones y no solo dos.

Regresando al tema de este post (después de un largo paréntesis), nuestro equipo fue restringido en tiempo, pero nos liberaron la variable del presupuesto, de tal forma que podíamos agregar más gente al proyecto (incurriendo en más gastos) pero deberíamos entregar en el mismo tiempo acordado. También acordamos entregar un núcleo de funcionalidad básico que satisfaciera las necesidades más apremiantes y que en versiones posteriores del producto podríamos entregar el resto de la funcionalidad.
Entregamos el producto para ser probado por el usuario antes de pasar a una etapa de uso definitivo. Una vez que el usuario empezó a hacer uso de su nueva herramienta empezó a retroalimentarnos con respecto a la funcionalidad. Empezamos a manejar largas listas de issues y tuve la necesidad de reportar diariamente el status individual de cada problema. Estas revisiones duraron semanas antes de empezar a reducir la frecuencia de la revisión.
En ocasiones, como Gerente del Proyecto me ví reducido a un Administrador de Problemas y eso no me agradaba. ¿Qué había de aquellos gráficos de Gantt y de la administración de los recursos? ¿Cómo se relacionaba mi trabajo actual (perseguir desarrolladores de sistemas en busca de status y de la solución de los problemas) con el Team Development, Project Procurement y Earned Value? ¿Qué tenía que ver mi junta diaria de quejas del cliente con el Risk Monitoring Control, el Cost Budgeting o el Performance Reporting?
En un momento dado hice un alto para reflexionar porque parecía que nunca iban a dejar de salir problemas y que nunca terminaríamos con esas estresantes reuniones de status en las que reportábamos 5 pendientes resueltos y me avisaban de 10 más.
Estas son las lecciones que aprendí una vez que salí de mi momento de introspección.

1. Si el cliente pudiera resolver su problema el mismo, no te hubiera buscado.
2. Cuando un cliente te elige para resolverle su problema, su problema se convierte en tu problema y debes resolverlo como si fueras el.
3. Independientemente de lo que se hizo bien y de lo que se hizo mal, hoy te encuentras en una situación que tienes que afrontar, asegúrate de hacerlo con el criterio adecuado: si eres desarrollador de sistemas, afronta tu situación como desarrollador de sistemas; si eres Gerente de Proyectos, afronta tu situación como Gerente de Proyectos.

Inmediatamente dediqué un recurso a buscar defectos en nuestro producto de manera proactiva (Quality Assurance) para no esperar a que el cliente los encontrara – así eliminamos la ansiedad y redujimos la molestia del cliente.
Saqué de mi mente los problemas de bajo impacto y baja prioridad – eso me dio “oxígeno psicológico” y pude pensar mas claro.
Una vez dominados los problemas existentes, regresé a mi lista de entregables (WBS) y a la definición de calidad que había definido para cada uno de ellos. Verifiqué que estuvieramos cumpliendo con todo como lo habíamos prometido (Quality Plan).
Hice una agenda de fechas en las que estaríamos atendiendo cada issue mayor (Schedule) e hice un estimado para su completación (Estimate To Complete).
Así fue como llevé mi aburrida tarea de administración de problemas de regreso al campo del Project Management. Nuevamente y a manera de conclusión, si vas a administrar problemas, asegúrate de hacerlo con criterio de PM. Si te toca hacer un post en un blog, asegúrate de hacerlo con criterio de PM. Si estás planeando tus vacaciones, asegúrate de hacerlo con criterio de PM. Esto hace más probable el éxito y hace todo mas divertido.

Palabra final: Si no te gustan los proyectos con problemas, entonces estás en la profesion equivocada: Un cliente nunca viene a darte soluciones, dinero, beneficios o a invitarte a pasar buenos ratos, el cliente siempre llega con un problema que requiere solución completa, rápida y barata.

Factores ambientales dentro del proyecto

Cuando trabajaba en una compañía pequeña en la que la mayoría de las cosas eran predecibles, para mi no tenía mucho sentido el "distraer" tiempo del proyecto en pensar qué factores ambientales de la empresa podían afectar a mi proyecto.
Cuando hablo de factores ambientales de la empresa, me estoy refiriendo a aquello que el PMBOK(1) describe en la página 83. Cito textualmente al PMBOK en su "definición" (para aquellos que no cuenten con una copia del PMBOK): "...se deben tener en cuenta todos y cada uno de los factores ambientales de la empresa y de los sistemas de la organización que estuvieran relacionados con el éxito del proyecto o pudieran influir sobre él de alguna manera."
En la compañía en la que trabajo actualmente iniciamos un proyecto de desarrollo de software en el que el equipo inicial lo conformábamos un Solution Architect, dos Technical Architects, ocho Developers, dos QA Testers y su servidor como Project Manager (PM). Yo a mi vez reportaba los progresos de ese proyecto a un Program Manager (PgmM) dado que mi proyecto era parte de un esfuerzo mayor en la migración de nuestro sistema de e-Learning.
El equipo de proyecto se encontraba distribuido en tres países: México, USA e India, en este último país tenía 3 de los desarrolladores.
Por algunos motivos que describiré en futuros posts dado que me han dejado grandes lecciones aprendidas, el proyecto empezó a acercarse a su fecha de entrega y, como sucede con frecuencia, los entregables no se acercaban a estar 100% terminados. La presión por parte de los directivos de USA era grande dado que el cliente a su vez los presionaba a ellos. Finalmente se estableció una fecha de entrega para que el usuario entrara a ver el producto terminado el Lunes 4 de febrero de 2008. La semana anterior todo el equipo estuvo trabajando a marchas forzadas, cuando de pronto el sub-equipo de India dejó de reportar sus avances. Inmediatamente noté la ausencia de su reporte porque dada la distancia geográfica que separa a la India de nuestro país y dado que las fechas eran muy agresivas, yo había implementado un reporte diario de avance con nuestros compañeros de aquel país. Esa noche me conecté cerca de las 2:00am CST (tiempo del centro) (1:30pm IST (tiempo de India)) para ver si podía localizar a los compañeros de allá y justo eso hice. Fue cuando me explicaron lo que había sucedido y que después confirmé en un comunicado de Yahoo! News: El viernes 1o de febrero, un barco en el mar mediterráneo ancló tras verse amenazado por el clima y cortó uno de los cables que comunican por Internet al Medio Este con Europa afectando gran parte del ancho de banda de la India y otros países.
En esta ocasión, más que dar Lecciones APrendidas ya digeridas, quiero compartir qué fue lo que hicimos para afrontar este problema y permitirles obtener sus propias Lecciones APrendidas (si las quieren compartir conmigo se los voy a agradecer mucho).

1. Comuniqué inmediatamente al PgmM y a los directivos de la compañía para que manejaran las expectativas con el cliente.
2. La mejor comunicación para el pueblo Indio se daba a media noche nuestra, y dado que unicamente podían comunicarse por email, al mas puro estilo de aquel granjero que se corta el dedo cuando le muerde una serpiente antes de que el veneno recorra todo su cuerpo, solicité a los recursos de India que enviaran por email su código fuente para terminarlo con los recursos de occidente. Como el granjero, cortamos miembros que desde luego nos serían útiles mas tarde, pero también cortamos un potencial problema mayor en ese momento, de otra forma, si hubiera permitido que "el veneno" se esparciera por todo el proyecto hubieramos sufrido una inminente muerte.
3. Uno de los arquitectos técnicos, quien me apoyaba manejando gran parte de las comunicaciones con el equipo de India y quien resolviera las dudas y problemas que a ese sub-equipo le surgían, fue asignado a concretar lo que los compañeros Indios dejaron inconcluso, así cerré la brecha de conocimiento que suponía el reasignar recursos del proyecto.
4. El proyecto ya estaba en problemas y con tres recursos menos y fechas agresivas, opté por dejar que el desarrollo continuara únicamente con recursos occidentales (USA y México). Posteriormente los colegas Indios nos apoyaron en algunas tareas de menor impacto mismas que hicieron muy bien.
5. Aunque ya contaba con un Risk Register, incluí dentro del mismo todo riesgo potencial para el proyecto y desarrollé planes de mitigación para aquellos con mayor probabilidad de ocurrir y mayor impacto.

Aunque todo este asunto parece (y de hecho es) un asunto de manejo de riesgos, quiero comentar que muchas veces pasamos por alto los factores ambientales que envuelven al proyecto o a la compañía y muchos de estos factores pueden presentar problemas. En la página 83 del PMBOK(1) se describen algunos de los factores ambientales que existen, en este caso nos vimos afectados en la infraestructura que rodea a la compañía.
Comparte conmigo y los demás lectores tus Lecciones APrendidas sobre este issue que ocurrió: ¿qué hubieras hecho en mi lugar?
De la misma forma te invito a enviar cualquier comentario o experiencia que consideres de interés general para poder crecer más en nuestro conocimiento de Administración de Proyectos.
(1) PMBOK 3ª Ed. Español Pág. 83

El retorno...

Hola otra vez.
Esta es una comunicación muy corta solo para comentar que estoy de regreso. Perdón a los lectores por mi ausencia - no voy a poner excusas.

Traigo material nuevo que voy a publicar poco a poco y muchas lecciones APrendidas de mi proyecto actual. Este se ha visto afectado de mil maneras: desde simples cambios de alcance hasta issues con un barco anclado en el mar Mediterráneo que dejó incomunicado al país de la India... adivinaste, tengo 5 recursos trabajando en la India.
En fin, vamos poco a poco.

Por lo pronto, bienvenido y muchas gracias por tu atención e interés. Especiales agradecimientos a quienes se han tomado el tiempo de escribirme, me honran con sus visitas al blog y su retroalimentación.

¡Saludos!

Project Manager vs. Team Leader

¿Te ha tocado ver cuando el adiministrador del proyecto deja su equipo de trabajo y el jefe se ve obligado a poner a otra persona? Normalmente el jefe elige al mejor miembro del equipo para administrar el proyecto, después de todo este individuo se merece el ascenso. Cuando eso sucede, normalmente decimos que el equipo perdió a un buen técnico y ganó a un mal administrador.
En México sucede que el crecimiento económico de un profesionista está muy ligado con el crecimiento de puesto o de responsabilidad, de tal forma que cuando una persona desea ganar más dinero es necesario que ascienda de puesto, porque en el puesto en el que se encuentra estará sujeto a un tabulador menor.
En el proceso, las compañías asignan puestos administrativos a tecnicos sin una preparación administrativa previa ni un proceso de “ramp-up” para el nuevo puesto, y el resultado no se deja esperar.

Un técnico está acostumbrado a “meter las manos” en el momento de implementación, mientras el administrador observa desde afuera. Un técnico “delegará” responsabilidad diciendo a su equipo Qué y Cómo hacer las cosas, un administrador solo dirá Qué hacer y esperará los resultados. Un técnico estará más preocupado por el tipo de implementación mientras un administrador estará preocupado por entregar dentro de los límites acordados de tiempo, costo y calidad. Un técnico facilmente caerá en la tentación del gold plating (funcionalidad extendida y mejorada) mientras un administrador se preocupa por entregar solamente lo solicitado por el cliente. Un tecnico dejará pasar nuevos requerimientos del cliente a costa de su fecha de entrega mientras un administrador filtra los requerimientos por su proceso de change management establecido desde el principio.

Algunos técnicos solo quieren la posición de liderazgo y el sueldo relacionado con esa posición, pero no las responsabilidades, así que se convierten en “técnicos bien pagados” dado que hacen lo posible por continuar metiendo su nariz en las decisiones y acciones técnicas y desacreditando la documentación, planeación, coordinación y comunicación del proyecto.

Lo más grave de todo es cuando escuchamos a un técnico quejandose porque “tuvo” que dejar aquello que lo motivaba, aquello “para lo que fue hecho”, para adoptar una posición administrativa que a sus ojos no agrega valor al proyecto.

1. Cuida a tus técnicos y desarrolla un plan de carrera para ellos.
2. Si “subiste” en el organigrama para ganar mas dinero pero detestas las actividades administrativas, piensa que en algún otro lugar pudieran estar premiando tus habilidades tecnicas sin necesidad de tenerte haciendo todos esos reportes y hablando con toda esa gente.
3. Cuando busques trabajo, revisa el anuncio primero: si piden un “Administrador de Proyectos” con muchas habilidades tecnicas, probablemente lo que quieran es un Team Leader. Si les interesa que conozcas metodologías de PM, que generes reportes para la PMO, que manejes los conflictos, que reportes avances, que administres la calidad, que salga el proyecto a tiempo, que administres el presupuesto del proyecto, etc., entonces quieren a un PM.

Conclusión:
En todo el mundo, las compañías deben aprender a remunerar la especialización de sus tecnicos para que tengan una ruta de crecimiento laboral y económico. Esto les permitirá seguir motivados haciendo lo que más les gusta hacer y dejar los puestos administrativos para aquellos que encuentran una pasión en eso. Por otro lado, para aquellos que quieren cambiar de profesión avanzando a puestos administrativos, las compañías deben considerar el desarrollar a sus empleados para que estos tengan una transición adecuada con el fin de que tengan éxito en su nuevo puesto administrativo. Esta transición requiere tiempo, requiere uno o más mentores y mucha capacitación. Todo esto requiere inversión, pero el retorno es en fidelidad del empleado y de mejores tecnicos y mejores administradores dentro de la compañía.

Comunicación in-¿formal?

Hoy en día estamos inundados de medios de comunicación, y no me refiero a los periódicos ni al radio o televisión, me refiero a la amplia gama de opciones que tenemos para estar en contacto con la familia, amigos y conocidos. Particularmente en el portafolio de herramientas del Project Manager se encuentran instrumentos de colaboración que son útiles para comunicar status de los proyectos, recibir notificaciones, enviar reportes, recibir retroalimentación, solicitar avances, etc.
Instrumentos como el mensajero instantáneo (MSMessenger, Yahoo Messenger, Lotus Sametime, Skype, etc.). Estas herramientas han evolucionado de manera muy positiva permitiendo ahora intercambiar archivos, compartir la visualización del escritorio de trabajo de algún colaborador e incluso ver y escuchar a nuestro interlocutor.
El capítulo 10 del PMBOK 3ra edición cubre el tema de la comunicación dentro de los proyectos. El primero de los procesos es la Planeación de la Comunicación y en su definición más básica en este proceso se “determina la información y las necesidades de comunicación de los stakeholders”.
Desde luego que la comunicación de la que habla el capítulo 10 del PMBOK es la comunicación del avance del proyecto, su status, los milestones y su cumplimiento, etc. La importancia de esta información sugiere una comunicación formal a través de juntas, minutas y/o correo electrónico. Pero hay una gran cantidad de comunicaciones que no se planean; es la comunicación informal, la información del día a día. Los pequeños acuerdos, la explicación de algo, ese instructivo que pasamos de mano en mano. Mucha de esta información viaja a través de los mensajeros electrónicos y no se lleva un registro de la misma. Vale mencionar que al no estar documentada, esta comunicación no forma parte de las lecciones aprendidas de un proyecto aún que sea información muy valiosa.

Un Project Manager debería considerar la clasificación y registro de este tipo de comunicaciones. Quizás habilitando la característica de “historial” de su mensajero instantáneo y estableciendo un esquema básico de categorías (por ejemplo: Crear categorías como “Información importante”, “Información Relevante”, “Información relacionada pero no importante o relevante”) un Project Manager pudiera controlar mejor este tipo de comunicación y sobre todo sacar ventaja de la misma.

Todo esto requiere dedicación, desgraciadamente los planes de comunicación que se hacen en las primeras etapas del proyecto difícilmente son revisados mas adelante. Igualmente las lecciones aprendidas: normalmente contienen issues que surgieron y se resolvieron durante el proyecto o explicaciones acerca de por qué hubo variación en el presupuesto de tiempo de una fase específica. Las lecciones aprendidas pudieran ser una base de conocimiento muy robusta si los PMs tuvieran la disciplina de revisar, clasificar y promover la comunicación informal a lo largo de todo el proyecto.

De regreso... otra vez...

Después de un poco mas de 3 meses de ausencia, he vuelto.
He estado envuelto en una serie de cosas nuevas en mi vida y eso me ha hecho retirarme de la escritura un poco. Un cambio en mi vida laboral movió no solo eso, sino muchas cosas mas, me dió nuevas oportunidades entre otras cosas. Pero bueno, sé que no estás aquí para leer sobre mi vida personal, sino sobre Administración de Proyectos.
Tengo muchas nuevas entradas para este blog en el tintero, así que no te pierdas (como yo) y regresa pronto, ya estaré entregando el siguiente post en no mas de 1 semana.
Un saludo a todos los lectores y por favor sigan mandando su feedback por cualquiera de los medios disponibles.

Cambio de trabajo

¡Hola! Espero que estén teniendo una semana santa de acuerdo a las expectativas y perfectamente apegadas al plan :)
Les debo una disculpa por mi ausencia en estas 4 semanas, mi "plan de comunicación" en este proyecto falló dado que "fuí asignado" a un proyecto mas grande y de mayor prioridad. En otras palabras, estuve en un proceso de reclutamiento para ingresar a otra compañía y, como pueden imaginar, después de más de 8 años de pertenecer a la misma compañía, no es fácil retomar el proyecto de cambio tan fácil, requiere tiempo, concientización, análisis de repercusiones, etc.
Como sea, yo sé que están acá tratando de leer alguna experiencia en administración de proyectos y no de enterarse de mis asuntos y mis forcejeos personales, así que aquí va una serie de LeccionesAPrendidas sobre este proyecto de búsqueda de trabajo manejada como un proyecto.

1. Empieza con un fin claro en la mente. Visualiza exactamente cuál es el puesto que deseas buscar/ocupar y describelo con detalle en un documento. Decide el tipo de industria a la que deseas pertenecer. Esto, como un plan de proyecto, te permitirá ver si te estás acercando al objetivo o si una propuesta es lo que estás buscando.
2. Elige dos o tres motores de búsqueda de trabajo, publica tu currículum y monitorealos cercanamente (al menos dos o tres veces por semana).
3. Acude a las entrevistas que te ofrezcan, si no es una buena oportunidad laboral, al menos te "desempolvas" en el asunto de ser entrevistado. Sé honesto y claro con el entrevistador y no generes expectativas que no vayas a satisfacer.
4. Al cierre del "proyecto", no olvides retirar o suspender tu currículum de los motores de búsqueda laboral cuando hayas encontrado y aceptado tu nuevo trabajo. Esto habla de profesionalismo y ética: cuando decidas "subirte en un tren, no te bajes a una cuadra de haber arrancado", ten en cuenta que la compañía ha invertido tiempo y dinero en el proceso de selección. Lo mejor es fijarse bien antes de aceptar una oferta y retirarse de la búsqueda por al menos un tiempo antes de empezar a buscar el siguiente escalón profesional.

Un par de anuncios para terminar:
1) ¡Ya tenemos el Nombre de Dominio www.leccionesAprendidas.com.mx! Si han creado un bookmark de esta página tomando la dirección de BlogSpot, les recomiendo que editen su bookmark y lo direccionen hacia esta nueva dirección. Esto es útil ya que si decidimos mover el sitio a otro hosting, ustedes no requerirán hacer actualización alguna, porque esta nueva dirección los redireccionará al nuevo sitio.
2) Estamos buscando nueva "casa". A pesar de que BlogSpot es muy efectivo, muchas empresas lo tienen filtrado en el proxy y la cantidad de usuarios lo ha hecho un poco lento. Así que estamos en el proceso de buscar un nuevo lugar donde publicar este sitio. Envíame sugerencias.

El Conocimiento es un activo de la organización (3ª parte)

Con un poco de retraso, pero aquí está el cierre de esta serie de Lecciones APrendidas acerca del conocimiento de las organizaciones.
Ya dijimos que el capital intelectual debe ser conservado dentro de la compañía independientemente de si la persona que lo produjo sigue dentro de la organización o ya se retiró. También comentamos qué son los OPA (ver post del 9 de febrero de 2007) y algunos ejemplos de lo que los compone.
Hice una revisión a detalle de los procesos de administración de proyectos detallados en el PMBOK 3ra edición en búsqueda del uso de los OPA. Ya comentaba que 26 de 44 procesos los incluyen como entradas al proceso y algunos de ellos tienen como salida la actualización del repositorio de conocimiento de la organización (aportaciones a la base de datos de conocimiento organizacional). Lo que llama la atención de esta reflexión, es que el uso de los OPA como entradas a los procesos es mas intenso en las fases iniciales del ciclo de vida de un proyecto como lo muestra la línea amarilla en la gráfica siguiente.

Y todo esto tiene sentido, conforme se conoce más acerca del producto, servicio o resultado a construir en el proyecto, la necesidad de consultar registros históricos disminuye. Al llegar al final del ciclo de vida del proyecto, dado que la cantidad de procesos de AP es muy pequeño (2 procesos) y en uno de ellos es usado, la estadística de uso de OPA se vuelve a levantar.
Todo esto nos deja varias lecciones, pero quizás las más relevantes para tu servidor sean las siguientes:

1. Los registros históricos de la organización son más necesarios al inicio del proyecto, de tal forma que los analistas y diseñadores deberán tener acceso a esos registros más que cualquier otro miembro del equipo.
2. Recordemos que el ciclo de vida del proyecto que sugiere el PMI encaja en cualquier metodología y establece que cada fase de la metodología tiene este mismo esquema: Inicio, planeación, ejecución, monitoreo y cierre, de tal forma que cada fase de la metodología usada haría uso de los OPA en los diferentes grados ya descritos.
3. Es necesario alimentar una cultura de aportación a la base de datos de conocimientos de la empresa. Toda inversión en este proyecto retornará en beneficios enormes en el futuro.

En mi compañía estamos por lanzar la nueva base de datos de conocimientos en el área en la que trabajo, sin embargo ya hay peticiones para que les prestemos espacio en la base de datos para subir las lecciones aprendidas de otros departamentos. Esto es algo muy positivo dado que usando la sinergia de un área, otras se benefician y la compañía crece. El lanzamiento es este viernes 23 de febrero, luego comentaré las Lecciones APrendidas de este proceso.
¡Hasta pronto!

El Conocimiento es un activo de la organización (2ª parte)

La semana pasada comentamos que la gente viene y se va de la empresa, pero el conocimiento debemos conservarlo dentro de nuestra organización.
El PMI se refiere a ese “conocimiento almacenado” con el nombre de “Activos de los procesos de la organización” (Organizational Proccess Assets). En delante haré referencia a ese conocimiento como OPA por sus siglas en inglés.
El PMBOK define que los OPA deben ser una entrada ¡para 26 de los procesos de administración de proyectos!, esto equivale a más de la mitad de los procesos existentes en ese framework.
En la vida diaria, ¿qué son los OPA? El producto intelectual de un trabajador es considerado un activo de la organización. Ya sea que esté plasmado en un formato (template), en un sistema computacional, un proceso innovador, una buena práctica, etc. este producto intelectual es un activo que si no “atrapamos” de alguna forma, cuando llegue el momento, podríamos descapitalizar a la compañía.
El siguiente escalón en la escalera de la capitalización de los activos intelectuales es el uso de los mismos: ¿cuántas veces la gente dentro de la empresa hace y re-hace las cosas? ¿No sería más económico consultar el repositorio oficial de conocimiento para ver si hay alguna información útil relacionada con lo que estamos a punto de hacer?
Desde luego que con el tiempo, la organización ya habrá adquirido alguna metodología estándar, se habrán desarrollado listas de verificación (checklists), se habrán creado procesos de atención, etc. Todo esto es la base de los OPA que sigue acrecentándose con el conocimiento desarrollado por los empleados o los mejores usos de aquellos OPA ya existentes.
¿Qué información contienen los OPA? Según el PMI, los OPA son aquellas “políticas, procedimientos, planes y guías formales e informales, cuyos efectos deben ser tenidos en cuenta” (1). De la misma manera, se consideran OPA “el aprendizaje y los conocimientos de las organizaciones adquiridos en proyectos anteriores” (1). De esto derivan los cronogramas, cotizaciones, código fuente, estudios de factibilidad, análisis de riesgos, etc.
Nuevamente en esta edición me quedé corto… la intención era terminar este tema esta semana, pero evidentemente necesitaré dedicar un nuevo post para los comentarios finales acerca de los activos intelectuales de la organización, así que, a manera avance, he aquí algunas Lecciones APrendidas:

1. Existe la tendencia de revisar las herramientas y técnicas de cada proceso y concentrarse en generar las salidas marcadas para ese proceso, pero pocas veces volteamos a ver las entradas o prerrequisitos para el proceso que abordaremos. No debemos ignorar las entradas, pueden ahorrarnos mucho tiempo valioso del proyecto.
2. Si no hay un método formal de almacenamiento de lecciones aprendidas en tu organización o al menos un método de colaboración en el que se pueda comentar acerca de los procesos, procedimientos, formatos y otros activos intelectuales… ¡esta es tu oportunidad para empezar el cambio!
3. Empieza por el primer peldaño y sube la escalera paso a paso. Quizás debieras empezar por tu archivo personal, ¿cuánta información valiosa acerca de proyectos pasados destruyes o “entierras” cuando termina el proyecto?
4. Apoya a tu organización a migrar de ser una organización que reacciona a ser una organización que aprende.

No estoy ni cerca de agotar este tema, pero como lo comentaba, los comentarios de su servidor cerrarán la próxima semana. Me entusiasma comentar que el día de hoy he recibido mi certificado de PMP cuyo examen aprobé el 21 de diciembre. Solo quería compartirlo con mis lectores y preguntarles, ¿tienes planes de buscar una certificación como administrador de proyectos?
(1) PMBOK 3ª Ed. Español Pág. 84

El Conocimiento es un activo de la organización (1ª parte)

Cuando alguien que hace muy bien su trabajo es promovido a otro puesto o es llamado por otra organización, normalmente deja un hueco, no solo en el lugar físico que dejó, sino en el conocimiento de la organización. Si la organización no “captura” ese conocimiento en algún medio, lo pagará a corto (resolución de problemas inmediatos) y a largo (curva de aprendizaje del nuevo elemento) plazos.
En un departamento de Sistemas o en empresas de consultoría de sistemas hay gente valiosa y creativa que disfruta con lo nuevo, estrena frecuentemente “gadgets” que lo hacen estar a la vanguardia de la tecnología y se entusiasma con los proyectos nuevos en los que participará. Es la misma gente que, en el lado obscuro del ejemplo, no gusta de dar mantenimiento a código que no hicieron ellos ni a aquel sistema que está en una tecnología antigua. Es ese tipo de personas que aborrecen el lado no-creativo o monótono del proyecto como lo es la documentación y que pasan por esa etapa del proyecto entregando el mínimo necesario para que les permitan poner su sistema en producción.

Hubo un tiempo en que en nuestra empresa la rotación de personal era un concepto lejano, pero llegó el momento en el que convirtió en un inconveniente. El problema lo experimentamos de inmediato en lo más evidente, pero conforme ha pasado el tiempo, nos hemos dado cuenta de que en la brecha del conocimiento de los sistemas, se ha ido mucho más de lo que hemos querido.
La mínima documentación y el almacenaje desestructurado dificultan gravemente la búsqueda de respuestas y, en ocasiones, se ha optado por rehacer alguna funcionalidad de los sistemas.
No a manera de conclusión, pero si como una introducción a la segunda parte de este post, permíteme adelantar algunas Lecciones APrendidas.

1. No esperes que sea cierto cuando un trabajador que se retira de la empresa diga “contáctenme para cualquier duda” ni tampoco si dice “cuando contraten a otro, yo vengo los fines de semana a enseñarle”.
2. Haz de la documentación un entregable del proyecto y define métricas de calidad para cada tipo de documento y verifica que se cumplan como en cualquier otro entregable.
3. La documentación debe estar almacenada de una manera consistente y centralizada en un repositorio público al resto del equipo de trabajo.
4. Comunica a todo el equipo cuando se genere un nuevo documento y desarrolla un procedimiento de atención a problemas (si no existe alguno en tu empresa) en el que uno de los procesos sea la revisión de la documentación existente.

En el siguiente post, concluiré con este tema comentando cómo el PMI se refiere a esta información almacenada y cómo sugiere su uso.
Mientras tanto, deja un comentario sobre cómo se maneja la documentación en tu compañía o equipo de trabajo. ¿A qué situaciones te has enfrentado y cómo las resolviste?

La planeación del alcance del proyecto

Estoy elaborando el documento de planeación del análisis (proceso 5.1 del PMBOK: Scope Planning) para un proyecto mediano de TI. En ocasiones la planeación del acance se confunde con el análisis del negocio y esto es un error. La planeación del alcance es la estrategia de cómo obtendremos los requerimientos y definiremos el alcance del proyecto. En otras palabras, la planeación del alcance es la metodología de análisis de requerimientos para el proyecto.
Para el PMI, el proceso de planeación del alcance no se limita a la planeación del análisis, sino que abarca la estrategia de creación del Work Breakdown Structure (WBS), establece el proceso de revisión y aceptación de entregables por parte del usuario y define el procedimiento a seguir cuando alguien solicite cambiar el alcance definido en la fase de planeación.
Mi documento contiene una sección para cada uno de estos aspectos en un formato estandarizado (bullets, tablas, etc.).
En lo personal me llevo algunas lecciones APrendidas de esta experiencia.

1. Elabora junto con el equipo de administraición del proyecto el documento de estrategia de análisis o plan de definición del alcance y establece las estrategias a emplear para el análisis, para la creación del WBS, para la verificación de los entregables y para la administración de los cambios de alcance.
2. Define dentro del documento algunas clausulas que protejan el desempeño del proyecto. Enunciados en los que se indique cómo proceder en el caso de determinado escenario (ej. Se espera que los usuarios reciban a los analistas en una sala de reuniones con acceso a la red y con permisos para conectarse a Internet)
3. Revisa los procedimientos, técnicas metodologías y templates que tengas disponibles para el proceso de análisis y sugiérelos en este documento. Esto le ahorrará tiempo de análisis a los analistas.
4. Revisa junto con los involucrados del proyecto el plan de definición del alcance y consigue su aprobación. En la revisión ellos concerán que deberán estar preparados para una serie de juntas, minutas, investigaciones, entrevistas, visitas o cualquiera que sea la estrategia que vayas a seguir para obtener los requerimientos.
5. Incluye este documento como un plan subsidiario del plan de proyecto. Modificalo cuando sea necesario (recuerda que un proyecto es elaborado progresivamente y eso incluye los documentos) y notifica los cambios inmediatamente. Mantén un log de las revisiones del documento (fecha y cambios mayores), un día puede servir.

“Otro documento… ¡como si fuera poco lo que ya hacemos!”. Cuando aceptamos la posición de Adminsitradores de Proyectos, de manera natural, aceptamos que nuestro trabajo sería coordinar gente, planear y documentar (la descripción de mi puesto no habla de la frustración de los resultados de esto, pero en fín), pero yo agregaría algo a esta (ya de por sí) pesada carga: mantener al corriente los documentos del proyecto. Los documentos deben permanecer vigentes hasta el final del proyecto. Ánimo… y ¡a documentar!

Crea una base de datos de los proyectos en los que has participado

El PMI no es una institución que te permita pagar y presentar el examen de certificación. En cambio, tienes que cumplir con varios requisitos de capacitación, experiencia y documentación y entre estos está el justificar tu experiencia como Project Manager por medio de la captura de los proyectos pasados en los que participaste.
Te solicitan capturar muchos datos acerca de cada proyecto (nombre, cliente, contacto, dirección del cliente, rol que jugaste, etc.), pero quizás el más grande de los requisitos es capturar las horas que invertiste en cada actividad de cada fase de cada proyecto en el que has participado.
Independientemente de si vas a buscar la certificación o no, es muy buena práctica registrar estos datos en una base de datos o en alguna hoja de cálculo. Si puedes almacenar el nombre del proyecto, el nombre del cliente, la fecha de realización (inicio y fin), los entregables que generaste y una descripción breve de los objetivos del proyecto, ya estás de gane. Sirve también registrar el tamaño del proyecto y al menos un estimado de los recursos invertidos (materiales y humanos).
En mi organización tenemos una base de datos donde tenemos registrados los más estos datos y un poco mas acerca de cada proyecto, esto me sirvió mucho en la tarea de capturar mi información curricular en el sitio del PMI.
Si es cierto que no tenía mucha información acerca de las fases ni los entregables, la base de datos que manejamos y unos cuantos “calculos” que a continuación te presento a manera de lecciones aprendidas, fueron de mucha utilidad para el proceso:

1. Al menos registra el nombre del proyecto, los objetivos del proyecto, el nombre del cliente, la fecha de realización (inicio y fin), los entregables que generaste, el tamaño del proyecto (en horas), un estimado de los recursos invertidos (materiales y humanos). Un día te van a servir.
2. Determina basado en tu experiencia el tamaño de los proyectos en los que has participado. Determina si el proyecto es chico, mediano, grande o extra grande. Esto te ayudará a empezar a dimensionar el esfuerzo.
3. Asigna una cantidad de horas invertidas en cada tamaño de proyecto, por ejemplo, en promedio un proyecto chico tarda 280 horas, uno mediano tarda 500 horas, etc.
4. Si necesitas definir cuanto tiempo te tardaste en cada fase, puedes definir qué porcentaje del tiempo se invierte en promedio en cada fase, por ejemplo, planeación del proyecto lleva el 25% del tiempo del proyecto. Si multiplicas la cantidad de horas promedio de tu proyecto por este pocentaje, tendrás el número de horas promedio que invertiste en esta fase del proyecto.
5. Si requieres calcular para cada fase cuántas horas invertiste en cada actividad de la fase, igual que en el punto anterior, define el porcentaje de tiempo que comunmente invertirías en esa actividad. Por ejemplo, La creación del WBS me lleva el 8% del tiempo de planeación. Si multiplicas este porcentaje por el número de horas invertidas en la planeación, tendrás el número de horas invertido en esta actividad.
6. Finalmente registra los entregables que resultaron en cada fase.

En mi compañía empezamos, mucho antes de necesitarlo, a registrar estos datos y años después nos sirvió en calculos de costo de proyectos y, en lo personal, me sirvió para calcular los tiempos invertidos para capturarlos en el proceso de certificación como PMP.
Para leer mas lecciones aprendidas con respecto a todo el proceso de certificación y el examen, visita el foro de PMHUB en la sección “Exam Preparation” en el foro “Lesson Learned/Exam Tips & Tricks” (http://forums.pmhub.net). El post de un servidor está bajo el título “LL of Fernando Valdez Borroel, PMP Monterrey, Mexico” con fecha 11 de enero de 2007.

De regreso...

Muy bien, ya estoy de regreso, después de un exámen de 4hrs, un trabajo que dejar al corriente y una bebé que cuidar durante mis vacaciones... al fin, el siguiente post.
Como lo anuncié, estuve ausente dado que estuve estudiando para el exámen del PMI que me acreditaría como Project Management Professional (PMP). Me complace reportar que pasé el examen y que me he unido a las filas de los certificados en Administración de Proyectos del PMI.
Quisiera dedicar un par de posts para relatar un poco esta experiencia siempre con el objetivo de entregarles información útil y digna de ser discutida aquí. He aquí el primero:

Acerca del exámen: El PMI, según he leido, se destaca por ser el instituto con la certificación No. 3 mas buscada en el mundo. Además ha recibido un premio por parte de la ISO que acredita el exámen como uno de los mejor elaborados para comprobar conocimientos. Con esto como background ¿qué mas puedo yo agregar? Simplemente algunas leccionesAPrendidas:
Lecciones

1. El examen es difícil.
2. Rara vez encontrarás preguntas conceptuales (lo que hace inútil confiar totalmente en tu memoria), mas bien son preguntas situacionales en las que deberás contestar cuál es el mejor curso de acción en una situación dada.
3. Practica con examenes de prueba. Hay muchos sitios que ofrecen preguntas gratuitas y otros con un bajo precio (49USD). El mejor ensayo es permanecer 4 horas concentrado en contestar preguntas, si pasas esa prueba, habrás sumado para la prueba final.
4. No dejes que la rigidez del proceso (agendar examen, acudir al aula Prometric, la revisión previa, las instrucciones del guía, etc) te cohiban o pongan nervioso. Solo son trámites que tienes que hacer.
5. Cuando termina el exámen una pantalla en blanco que dura unos 40 segundos te hace pensar que hiciste algo mal. No te preocupes, espera pacientemente el resultado.
6. No esperes que empiecen con las preguntas fáciles, si la primera pregunta es difícil, no te pongas nervioso(a).
7. No te preocupes si te pasas de 72 segundos por pregunta durante las primeras 50, pero trata de cerrar esa brecha. Ajustate a 60 o 70 segundos por pregunta, eso te va a dar de 10 a 30 minutos para revisar tus respuestas al final.
8. El PMBOK es un "must" para estudiar para el examen, pero no trae toda la información que necesitas. Revisa las notas de el curso de certificación que hayas tomado o compra algún libro de "PMP Preparation".
9. Aunque el PMI evalúa la experiencia, el examen presenta situaciones en muchos de los casos no de la vida real, así que no confíes en tu experiencia, mejor aprende los términos del PMI.
10. Si no pasas a la primera, sabe que la mayoría no lo hace. Entiende que no eres el primero en fallar. No te desanimes, presenta otra vez. Date un par de meses para reestudiar. Revisa en qué fallaste y ahonda en esos temas. Repasa los que ya dominas y no te metas a mucha profundidad en ellos, mejor invierte en aquellos en los que no dominas.

Bueno, asumí que los lectores querrían saber algo acerca del examen de certificación para PMP, así que espero que esta mini guía de consejos les sirva. ¿Alguna otra sugerencia?

A mis dos lectores...

Yo sé que no he escrito, pero estoy en mis últimos días antes de presentar el exámen de certificación del PMI. Les pido paciencia...

No se me ha ido la inspiración ni se me apagó la calentura, tengo un par de posts medio escritos que, a mi juicio, son de mucho valor, pero considero que Ustedes se merecen una buena redacción y LeccionesAPrendidas de calidad.

Gracias por su paciencia.
¡¡¡Saludos!!!

Fernando Valdez B.