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.

Requerimientos… ¿con fecha de caducidad?

Estuve en un proyecto en el que el usuario que definía la funcionalidad solicitó algo cuyo costo de construcción implicaba cambios importantes en varios productos que ya estaban en operación y desarrollarlo elevaba el costo del proyecto en un 50%, sin embargo la funcionalidad solicitada no elevaba el valor del producto final en una cantidad proporcional. En otras palabras, el usuario definidor solicitó funcionalidad de alto costo y bajo impacto.
Lo que hice en ese caso fue solicitar una autorización formal incluyendo información de costo del desarrollo, impacto de tener la funcionalidad, impacto en riesgos para el proyecto y en la fecha de entrega.
En el ambiente organizacional de esa empresa, cuando no se quería tomar una decisión, simplemente no comentaban al respecto. Para evitar problemas, incluí una clausula en la que decía que si no recibía autorización por escrito de este cambio a mas tardar en 72 horas, el requerimiento quedaría excluído del alcance del proyecto.
Tal como lo estás pensando, no recibí respuesta y el requerimiento “caducó”.
Después me preguntaron acerca de si se había incluído (aquellos usuarios que fingieron demencia acerca de mi comunicado, como si nunca lo hubiera enviado) y me orgullecí haciendo referencia a los dos recordatorios que envié antes de que caducara la solicitud.
¿Qué aprendí?

Lección 1.- Debemos establecer un medio formal por el cual se autoricen o rechacen los cambios en el proyecto (costos, tiempo, calidad, etc.)
Lección 2.- La cultura organizacional es un input importante al iniciar un proyecto.
Lección 3.- No se trata de “cubrirse”, se trata de satisfacer expectativas. En esta lección entra la proactividad: si hubiéramos dejado caducar el requerimiento sin hacer el esfuerzo por obtener respuesta, hubiéramos sido calificados como inflexibles. De esta otra forma, la gente se queda con la idea de que somos firmes, pero que estamos haciendo lo posible por hacer las cosas bien.

Al menos estas tres lecciones por ahora, ¿qué habrías hecho tu?

¿Proyectos dentro de otros proyectos?

Estoy en la fase de cierre de un tedioso, largo, desgastante y retrasado proyecto.
Es dificil frente a un usuario mencionar las palabras "de acuerdo", "aprobación", "conclusión", "visto bueno", etc. cuando se culmina un proyecto con aquellas características. Pero es mas dificil vender la idea de una celebración para dar por terminado el esfuerzo de meses de varios equipos de trabajo.
Como sea, estoy planeando la junta formal de cierre y la posterior celebración.
Para no hacer el ridículo frente a toda la gente reunida, me aseguré de hablar previamente con todos para ver si "habría algún inconveniente o pendiente aún abierto que impidiera que tuvieramos esa reunión". Afortunadamente recibí la aceptación de todos (dado que el producto se ha entregado y ha pasado un proceso de mas de 2 semanas de estabilización sin presentar problemas importantes).
Dentro de la presentación estoy incluyendo al inicio una explicación de "qué no es esta reunión"; aquí incluyo cosas como "no es una junta de revisión de avances, mucho menos una de análisis de requerimientos", etc.
Una vez aclarado el asunto, vamos a los objetivos del proyecto, el status, como manejaremos los problemas que se presenten con el producto, los siguientes pasos y un espacio para dudas y preguntas.
Finalmente, una vez terminada la presentación de la junta de cierre, me dediqué a planear la reunión de celebración de fin de proyecto. Hice el plan de quienes vamos a invitar, la agenda para ese día, el lugar, la invitación, los snaks y bebida, etc. Me encontré que esta fiestecita ¡es todo un proyecto! Tengo que obtener la autorización de cierre del usuario (charter), planear qué componentes tendrá la celebración (wbs), qué actividades se llevarán a cabo (scope planning), a quienes invitaremos (stakeholder analysis, human resource planning), cómo les mandaré la invitación (communications plan), con qué presupuesto contamos (cost estimation), planear qué vamos a comprar (plan purchases and acquisitions), cuándo la llevaremos a cabo (milestone list), ¿qué haremos si el cliente no puede? (risk analysis), ¿hasta qué punto queremos agasajar a los invitados? (quality planning)...

¿Será que es todo un proyecto? o... ¿¿¿será que todo lo veo como un proyecto???...

Lección 1.- Si vas a celebrar al final, asegurate de reservar parte del presupuesto de tiempo y costo para esta actividad.

Lección 2.- Aquí se puede ver con claridad la naturaleza iterante del ciclo de vida de un proyecto: Inicio, Planeación, Ejecución, Monitoreo y Control y Cierre.

A ti, ¿cómo te gusta celebrar el fin de un proyecto?

¿Cuánto estás dejando de ganar por no concluir el proyecto?

Estuve en un proyecto grande en el que teníamos al patrocinador muy involucrado en la definición de los requerimientos y en la revisión de los entregables. Dada su alta jerarquía en el organigrama funcional y la estructura de discusión y toma de decisiones de ese tipo de ejecutivos, todas las reuniones de revisión se convertían en "sesiones de captura de necesidades" (como si estuvieramos en etapa de planeación y análisis) y, obviamente, el alcance se extendía casi al mismo ritmo que el tiempo que pasábamos en su oficina.
El usuario que se supone definiría la funcionalidad apoyaba ciegamente los cambios de alcance y funcionalidad sin oponerse.
Los nuevos requerimientos iban siendo autorizados sin problemas, pero el proyecto se "barrió" mas de 4 meses más de lo planeado. El argumento siempre fué "la inversión en la nueva funcionalidad se justificará en 1 mes cuando el producto esté en operación". El proyecto se alargó a mas del doble de tiempo, el equipo se desgastó, el usuario quedó molesto y el equipo de administración del proyecto igualmente.
¿Qué aprendí?

Lección 1: ¿Realmente se hizo un análisis exahustivo de los entregables y del beneficio que traería el alcance definido al inicio del proyecto? ¿Por qué no se detectó toda esa nueva funcionalidad y se integró como parte del proyecto original? ¿Es que el patrocinador se "coló" entre el grupo de usuarios definidores sin ser notado (error en el análisis de stakeholders)? El patrocinador no fué identificado en su rol de definidor: error en el análisis de stakeholders.

Lección 2: Si hubieramos hecho un análisis de los beneficios que producirían los entregables planeados podríamos haber tenido un argumento sólido para detener el alargamiento del proyecto. Hubiéramos dicho "ok, construiremos eso también pero quiero recordarles que estamos dejando de ganar X miles de pesos este mes dado que no hemos salido a operación". Estoy seguro que la primera vez probablemente no tendría el impacto deseado, pero cuando le reportemos que ya no son X sino 2X lo que se ha dejado de ganar, reaccionarían (hopefully).

¿Encuentras otra lección en esta experiencia?

Planear la planeación...

Acabo de cometer un error. Pero cobijado con ese dicho de "las lecciones se aprenden con los errores cometidos" y con aquel que dice "se aprende mas de los errores..." les transmito esta Lección APrendida.
Estoy adminsitrando un proyecto tratando de apegarme al estándar del PMI. En este proyecto hay fechas fijas y no negociables: no podemos ir mas allá de la fecha definida.
Empecé dividiendo en fases el proyecto y arranqué con la fase de Inicio. Después de un kickoff apresurado, empalmado entre fases pero exitoso, continué con la fase de Planeación. Fuí exhaustivo en el seguimiento a los procesos de planeación que dicta el PMI. Llegó el momento de entrar en detalles técnicos y, como es mi costumbre, involucré a aquellos especialistas que pudieran ahondar en los "tecnicismos". Hasta entonces teníamos claro el objetivo del proyecto y las actividades (a alto nivel) necesarias para generar los entregables. Hasta hicimos un documento de análisis que se suponía nos ayudaría a prever cualquier problema en potencia. Yo insistí en llegar a un siguiente nivel de detalle en el análisis técnico dado que es un proyecto muy importante, pero no insistí. Finalmente confié en que el personal tecnico tenía todo bajo control y dada la prisa dado que las fechas se estaban cumpliendo, acepté poca profundidad en el detalle y acepté arrancar con un "si terminamos para esa fecha" y sin un cronograma detallado de esas actividades específicas.
La planeación de lo demás iba muy bien, llegamos a profundidades casi inecesarias y esto justificó en mi mente la falta de profundidad del análisis técnico.
La "venta" se hizo y se comprometieron fechas. En la ejecución todo empezó bien. Yo hice monitioreo de avances pero no en una base de entregables y dado que no teníamos un nivel de detalle aceptable ni fechas ligadas a entregables, me limité a preguntar "¿si terminamos para esa fecha?" a lo que siempre recibí un "si".
Finalmente 3 días inhábiles antes de la entrega la gente técnica descubre algunas actividades que eran necesarias y que llevarían alrededor de 2 días de trabajo.
Finalmente tuvimos que trabajar esos 2 días y los entregables se terminaron a un 97%.
El punto aquí es que no cumplimos con el 100% ni lo hicimos en horarios hábiles sino que sacrificamos tiempos de descanso por cumplir con la fecha establecida.
La administración exitosa de un proyecto no es entregar cuando dije que entregaría, sino que debemos cuidar del desgaste al equipo. Desde esta perspectiva y muchas otras que habrás identificado, el proyecto no fue excelentemente administrado. ¿Qué aprendí?

Lección 1: Empalmamos fases de planeación entre planeación de la administración del proyecto y la fase de planeación o análisis del proyecto. Es decir, la fase de ejecución de la administración del proyecto debe incluir toda la metodología de desarrollo: análisis, diseño, construcción, pruebas, liberación. En esta metodología, el análisis y diseño son las fases de planeación, pero caen dentro de la fase de ejecución del plan de administración de proyectos.
En otras palabras, la planeación de la administración del proyecto fué exhaustiva, pero la planeación técnica fué deficiente.

Lección 2: También es posible que se empalmen las metodologías y que la fase de planeación tecnica tenga parte dentro de la planeación de la administración del proyecto, pero ambas deberán ser exhaustivas. Lo completo de una no reemplaza el ejercicio de completar la otra.

Lección 3: Nunca la prisa reemplaza la necesidad de la planeación, la creación de un cronograma ni la definición de entregables.

Lección 4: La mala planeación desgasta al equipo.

¿Encuentras más lecciones en este caso?

¿Qué variable le interesa MAS a tu usuario o cliente?

Un usuario (cliente) siempre va a tener preferencia por alguna variable del proyecto: Calidad, Tiempo, Costo, Alcance, etc. Casi todas las preguntas que haga, las empezará con preguntas sobre esa variable. Ejemplo: Si la variable "favorita" es el tiempo, sus preguntas serán "¿cuándo empiezan con mi proyecto?", "¿cuándo lo acaban?", "¿cuánto falta para terminar este entregable?", etc.

Procura siempre tener a la mano los dos o tres indicadores del área de mayor interés para tu usuario: Si le importa más el tiempo, ten lista la fecha de inicio, la de fin, milestones, forecasts acerca del calendario, SPI, etc.

¿Industria o AP?

¿Qué habilidades son mas necesarias en un proyecto?

a) El conocimiento en la industria en la que se desarrolla el proyecto
b) Al conocimiento en administración de proyectos

¿Qué opinas?

¿Quién es el Patrocinador?

El Patrocinador del proyecto es ese integrante del equipo de proyecto que define qué quiere y sugiere cómo hacerlo.

Hay que hacerle caso en lo primero y cuestionar lo segundo.