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?