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.

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?