miércoles, 12 de septiembre de 2007

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.

miércoles, 15 de agosto de 2007

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.

martes, 17 de julio de 2007

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.

sábado, 7 de abril de 2007

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.

miércoles, 21 de febrero de 2007

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!

viernes, 9 de febrero de 2007

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

jueves, 1 de febrero de 2007

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?

jueves, 25 de enero de 2007

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!

miércoles, 17 de enero de 2007

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.

Where am I (in the world)?

Where am I (in the city)?

Visitantes

free counters