Mailchimp

lunes, 29 de junio de 2020

Las Tres Preguntas que todo Director de Proyectos Debe Responder




Cómo en toda organización o grupo orientado hacia un fin determinado, siempre debe haber alguien en la cabeza controlando que todo salga cómo está previsto. Los Directores de Proyecto son exactamente eso, los encargados de que el Proyecto avance y finalice exitosamente cumpliendo con todas las exigencias y desarrollando todos los entregables.

 

Son muchos los factores que tienen que tener en cuenta los Directores de Proyecto a la hora de embarcarse en su ardua tarea, y también son muchos los documentos, artículos y cursos PMP online que abordan el tema y le entregan a los futuros Directores de Proyecto múltiples enfoques y perspectivas sobre cómo desarrollar su función de la mejor manera posible.

 Recopilando toda esa información que se encuentra al alcance del que la quiera analizar, podemos determinar que un Director de Proyectos es una persona apasionada por su trabajo, organizada, con la mente abierta y enfocada a las metas. Los Directores de Proyecto entienden el rol estratégico que poseen los Proyectos y comprenden la importancia que representan a la hora que una organización se proponga crecer, cambiar, aprender y tener éxito. Toman las metas y objetivos del proyecto como propios utilizando su experiencia y las habilidades adquiridas gracias a ella para aumentar la confianza en el equipo e inspirar a los demás. Disfrutan de la presión sintiéndose cómodos con la complejidad de los problemas y el cambio en el cronograma obteniendo una visión general de todo lo que acontece en el Proyecto, percatándose de los detalles que pueden a la larga ser cruciales y otorgándole a cada obstáculo la importancia suficiente.

 

Por si fuera poco, los Directores de Proyecto también se preocupan por los demás, cultivando las habilidades interpersonales idóneas para generar confianza en el equipo y aumentar la comunicación, que a fin de cuentas puede ser uno de los factores que más soluciona problemas durante el ciclo de vida del Proyecto, utilizando una amplia gama de herramientas para resolver malentendidos entre el personal, desglosando actividades complejas y problemáticas en tareas más pequeñas a las que se les puede dar seguimiento y control. Un Director de Proyecto se adapta a las limitaciones encontrando soluciones nuevas e inesperadas, siempre están mejorando sus habilidades y se esmeran porque su equipo haga lo mismo, porque la experiencia es una de sus mejores armas y no hay mejor forma de obtener experiencia que de las lecciones aprendidas.

 

Dos párrafos parece que no son suficientes para exponer todos los factores que un Director de Proyectos debe poseer. Se podrían escribir muchos más y sin duda existen muchos otros artículos de preparación PMP con diferentes enfoques y temas que resaltan las características de un Director de Proyectos. De momento hay tres preguntas que todo Director de Proyectos debe conocer: ¿Cuánto?, ¿Cuándo?, y ¿Qué?

 

¿Cuánto?: La pregunta de la cantidad. Para poder realizar todas las tareas y cumplir con todas las características que se han mencionado hasta el momento sobre los Directores de Proyecto, que sería de uno de ellos si no conociera cuánto trabajo se debe desarrollar para conseguir el éxito. Comenzando por ¿cuánto presupuesto hay disponible?, ¿cuántos materiales se deben conseguir?, ¿de cuánto tiempo disponemos?, ¿cuántas actividades se deben desarrollar para crear un entregable?, y así sucesivamente.

 

Un Director de Proyecto debe preguntarse constantemente cuánta es la cantidad de trabajo que se espera se desarrolle en un tiempo determinado, teniendo en cuenta todas las cantidades que estén involucradas en dicho proceso: materiales, tiempo, recursos, dinero y personal.

 

¿Cuándo?: La pregunta del tiempo. Si un Director de Proyecto debe saber cuántos recursos se necesitan para desarrollar determinada actividad no menos importante debe ser el conocer cuándo se va a desarrollar dicha actividad. Todas las actividades del proyecto deben tener un tiempo de desarrollo definido desde el Cronograma de Proyecto, y lo que define el Cronograma es cuándo se van a desarrollar las actividades, cuándo se van a adquirir los recursos, cuándo se terminarán los entregables y cuándo se van a cumplir las metas. Aquí se encuentra tal vez una de las preguntas más importantes que un Director de Proyecto debe tener siempre en mente: ¿cuándo finalizará el proyecto?

 

¿Qué?: La pregunta de los objetivos. Si ya se conoce cuánta cantidad de recursos se necesitan y para cuándo, lo siguiente es preguntarse ¿y para qué se necesitan? Es aquí donde el Director de Proyecto utiliza sus habilidades interpersonales para asignar tareas y desarrollo de actividades a los miembros del equipo más idóneos indicándoles qué es lo que deben realizar. ¿Qué actividades se deben desarrollar?, ¿qué materiales se necesitan para el desarrollo de los entregables?, ¿qué tareas debe desarrollar el departamento de control de calidad?, etc.

 

Estas tres preguntas están íntimamente relacionadas y responder una nos lleva a preguntarnos cuál sería la respuesta de la otra. Son tres preguntas que todo Director de Proyecto debe tener siempre en cuenta para que todo salga de la mejor manera posible.

 

Los Directores de Proyecto se pueden encontrar en todas partes y en diferentes organizaciones. Algunos son empleados, otros gerentes, contratistas o consultores. Todos ellos necesitan preguntarse ¿cuánto?, ¿cuándo? y ¿qué?, si quieren desarrollar un buen trabajo como Directores de Proyecto. Hay muchas más preguntas relevantes que se deben tener en cuenta, y mucha más información respecto al rol de los directores que puede ser encontrada en el PMBOK 6 o en diferentes sitios online. Lo importante es tomar todas las opiniones en cuenta y aprender de la experiencia de los demás, solo así se puede ser un gran Director de Proyectos y/o superar el examen PMP.

lunes, 22 de junio de 2020

Caso de estudio PMP e ITIL: Teoría y Práctica




 

En 2007 La OSR, Organización de Servicio de Registro, afrontaba uno de los momentos más difíciles desde su fundación. Con más de 200 oficinas a nivel nacional carecía de un sistema de información eficaz. El sistema estaba diseñado según el esquema básico cliente-servidor y presentaba inconvenientes en el diseño de la arquitectura y procesos. La descentralización del sistema generó silos de información, aumentando costos en el  mantenimiento, control y coordinación del SIR (Sistema de Información de Registro).

Por su parte, las directivas de la OSR realizaron una licitación pública en 2004 la cual ganó la unión temporal WB (en adelante contratista), conformada por las compañías Willie Nelson Systems Inc y Bacatá Telecomunicaciones. El objeto de la contratación era realizar la migración del sistema SIR a uno centralizado cuyo nombre sería SIRC. Sin embargo, a 2007 el contratista sólo había conseguido migrar 30 oficinas de las cuales cinco correspondían a ciudades principales. Lo anterior representó sólo ⅕ de  toda la información de la OSR a nivel nacional.


Debido a esta situación fue necesario delegar el problema a un director de proyectos llamado Miguel Huertas. El director de proyectos determinó llevar a cabo un proceso de auditoría para el contratista por intermedio de una entidad externa denominada Phil Audit. Los resultados de la auditoría mostraron los siguientes problemas:


  • Canales de comunicaciones insuficientes.
  • Demoras en los tiempos de respuesta de la Mesa de Ayuda.
  • El personal de las 30 oficinas migradas no estaba capacitado para operar de manera efectiva el SIRC.
  • El rendimiento del software no era el esperado, presentaba demasiados errores de funcionalidad.
  • No había un seguimiento del cambio de los requerimientos del software. No estaban claras las responsabilidades del contratista en caso de errores e inconvenientes en la aplicación del SIRC.

A nivel de dirección del proyecto PMP, Miguel tuvo que conformar un equipo de trabajo para poder coordinar y ejecutar la acciones que permitieran encontrar las causas de los problemas, así como sus soluciones. El equipo estaba conformado por representantes de las dos entidades contratistas; un representante de las directivas, otro de funcionarios de la OSR y un representante de la Mesa de Ayuda.


Miguel empezó a trabajar directamente con la Mesa de Ayuda puesto que es la parte de la organización que presta servicios de gestión y solución a incidencias del sistema experimentadas generalmente por el usuario final, el ciudadano.


La representante de la Mesa de ayuda, Laura Jiménez, informó al director de proyecto la transición en la que se encontraba el Centro de Atención al Usuario. Las directivas habían decidido implementar el marco de referencia ITIL, la Biblioteca de Infraestructura de Tecnologías de la Información, el cual permitió brindar un servicio de soporte integral. Debido a esto el Centro de Atención al usuario cambiaba su nombre por el de Centro de Servicios.


La OSR decidió implementar un Centro de Servicios tipo service desk local para las treinta oficinas migradasEn ITIL este tipo de servicio es el adecuado para negocios con necesidades locales ya que permite tener varios service desk en cada localización geográfica y optimizar el tiempo de respuesta para la solución de incidencias. Sin embargo, Laura Jiménez se mostró escéptica respecto a aquella decisión; pues a pesar de la optimización en tiempo de respuestas, el Centro de Servicios de esa característica presentó las siguientes desventajas:


  • Mayores Costos
  • Difícil monitoreo
  • Poca optimización de los recursos
  • La gestión de incidencias no mejoró


De igual manera, el Director de Proyecto fue informado acerca de los componentes de la Mesa de Ayuda de la OSR que, según la representante Jiménez, son roles particulares que adoptan los integrantes dentro de la misma. Se tenía un personal encargado de resolver solicitudes simples; la mayoría comunicadas vía telefónica y que podían ser resueltas casi al instante. Este personal brindaba un soporte de primer nivel. El siguiente rol era el soporte de segundo nivel; correspondiente a grupos técnicos encargados de resolver solicitudes de mayor complejidad en las que se requería llevar a cabo procesos determinados según la espacialidad de la solicitud. El último componente era el nivel de supervisión; en el cual la señorita Jiménez como supervisora de la Mesa de Ayuda ejercía una influencia directa ya que era donde se efectuaba el seguimiento y control del correcto funcionamiento de estándares aplicados a los tiempos de resolución de cualquier solicitud.


Así que Miguel decidió identificar cuáles eran los problemas que generalmente los usuarios experimentaban y que requieren un soporte de primer nivel, segundo nivel y otros problemas que precisaban supervisión. También recibió los informes periódicos que la Mesa de Ayuda emite a las directivas para la toma informada de decisiones.Posteriormente, recurrió por consejo de la supervisora al administrador del software actual de la Mesa de Ayuda, el ingeniero Camilo Rodríguez. El ingeniero brindó información sobre el comportamiento mensual de los índices y datos del servicio, así como el intento por efectuar acuerdos a nivel de servicio para la temporal, los cuales no fueron debidamente desarrollados y ejecutados.


Simultáneamente, coexistía un problema relacionado con las comunicaciones de la OSR. La infraestructura de telecomunicaciones difería entre las oficinas de ciudades grandes y  pequeñas; mientras que la tecnología de unas estaba provista de banda ancha, la información transmitida a otras era vía satélite.

En definitiva, la OSR no había logrado una migración exitosa de su sistema de información, optimizar los costos del Centro de Servicios y solucionar los problemas derivados de las comunicaciones e infraestructura.

Preguntas Clave


De acuerdo a la anterior situación problemática Miguel Huertas debía lograr comprender el origen de los problemas de la OSR. Por otro lado, las directivas de la organización consideraron necesario establecer un estándar para la gestión de proyectos. Debido a esto el director de proyecto comenzó a identificar las preguntas rectoras que desde la metodología PMI dieron claridad en la comprensión del problema.

Planeación

La primera de estas fue ¿Qué falló desde la metodología PMP?. El director de proyecto identificó que muchos de los problemas de la OSR tenían su origen en la planificación del proyecto para centralizar el sistema SIR. El proyecto tenía un plan que sólo comprendía cronogramas de actividades y la discriminación de la ejecución del presupuesto. Por consiguiente el plan no contenía directrices para situaciones como las que presentaba la OSR. También este plan carecía de un juicio de expertos para las situaciones que se presentaran o los cambios que se fueran durante la gestión del proyecto.


Sin embargo el director de proyecto debía identificar los procesos del grupo de planeación que según el PMI no se realizaron correctamente. De allí surgiría la una pregunta secundaria que ayudaría a resolver la primera ¿Qué procesos de planeación fallaron en el proyecto?


El plan de proyecto comprendía la ejecución detallada del presupuesto y una completa descripción del cronograma, por tanto Miguel determinó que había fallas en los grupos de procesos de alcance, recursos humanos, comunicaciones y riesgos.

Alcance

El primer inconveniente identificado radicaba en que las directivas tenían como plan de gestión el acta de constitución de la OSR: los entregables del proyecto que debía presentar el contratista estaban identificados de manera global. Por tanto era preciso elaborar un plan de gestión del alcance que describiera detalladamente los entregables que correspondían a Willie Nelson Systems Inc y Bacatá Telecomunicaciones.

Riesgos
Un aspecto importante de la planificación de cualquier proyecto es planificar la gestión de riesgos. En el ciclo de vida de un proyecto existe un grado de incertidumbre de riesgos imposible de mitigar en su totalidad pues no se sabe a ciencia cierta qué factores externos o internos afecten el contexto del proyecto. Sin embargo es posible prever los riesgos del proyecto y minimizar el impacto de sucesos negativos.


Para el proyecto SIRC de la OSR no se realizó una planificación de los riesgos. El contratista puso en marcha su actividad y la dirección del proyecto no contempló las dificultades que presentó el software en su rendimiento. De igual manera no tuvo presente las inconsistencias contractuales que se presentaron entre el desarrollador del software y su operador, es decir entre Willie Nelson Systems Inc y Bacatá Telecomunicaciones. Por consiguiente la pregunta a responder fue ¿cómo realizar una planificación de la gestión de los riesgos el proyecto?


El director de proyecto y su equipo realizaron cinco procesos de planificación de los riesgos independientemente de que estos ya se hubieran presentado, a saber: planeación de la gestión del riesgo, identificación de riesgos, análisis cuantitativo de los riesgos, análisis cualitativo de los riesgos y planeación de la respuesta a los mismos.


Al planificar la gestión de los riesgos, el equipo y el director de proyecto analizaron y anticiparon los riesgos de corregir los problemas en el proyecto de centralización del SIR. En términos prácticos la planificación se materializó en un documento estratégico que detalló cómo la gestión de riesgos se llevó a cabo a lo largo del proyecto. Un factor elemental en la  planificación en este punto fue determinar el nivel de riesgo que la OSR podía enfrentar.


Posteriormente identificaron los riesgos de procesos anteriormente realizados en fases como el alcance, cronograma, presupuesto y comunicaciones del proyecto. De igual manera identificaron factores ambientales correspondientes a las actitudes de los interesados hacia el riesgo. Para analizar todos los riesgos emplearon técnicas analíticas y juicios de expertos en los tipos de riesgos identificados. Como resultado obtuvieron el plan para la gestión de los riesgos.


Dentro de dicho plan contemplaron las amenazas y oportunidades que representan los riesgos que afrontaba la OSR y los que probablemente tendría. El director de proyecto detalló los diferentes riesgos involucrando los planes de las fases anteriormente mencionadas del proyecto con el fin de explotar las oportunidades y responder efectivamente a las amenazas.


Su equipo trabajó en el procesamiento y análisis de los riesgos identificados a partir de técnicas de documentación y recopilación de información, análisis de lista de control, análisis de hipótesis, técnicas de diagramación para la producción de diagramas de flujo y un análisis DOFA. Como resultado obtuvieron un documento detallado denominado registro de riesgos. Este proceso de identificación de riesgos fue revisado varias veces debido a que en en el ciclo de vida de un proyecto se pueden presentar más riesgos de los esperados.


El siguiente paso fue priorizar todos los riesgos identificados realizando un análisis cualitativo. En el caso de la OSR se abordaron primero los riesgos del sistema de información y los problemas de migración. En este aspecto definieron categorías para los riesgos del SIRC y registraron los problemas que se presentarían en este. Para procesar estos problemas realizaron una evaluación de la probabilidad del impacto de los riesgos en el costo, calendario, alcance y calidad del proyecto. Dicha información fue organizada en una matriz. El resultado de esta planificación se expresó en una actualización de todos los documentos del proyecto.


Luego de realizar un análisis cualitativo se efectuó un análisis más a fondo de los riesgos de prioridad alta, un análisis cuantitativo de los riesgos. Mientras que en el primero se realizó una categorización subjetiva de los riesgos, en el segundo se asignó un valor numérico de cuánto dinero podría perderse en el proyecto.


En ese sentido se determinó que el 80% de incidentes tenían su causa en el 20% de problemas del SIRC. El principio de Pareto se confirmó también para los problemas que Phil Audit identificó. El análisis cuantitativo respaldó las categorías y el proceso que se llevó a cabo en el análisis cualitativo. Como resultado se obtuvo una actualización de la documentación del proyecto.

Por último, el director de proyecto presentó la manera más adecuada de enfrentar los riesgos frente al SIRC y los diferentes procesos organizacionales de la OSR. Luego de haber planificado la gestión de riesgos, haberlos identificado y analizado cualitativa y cuantitativamente abordó los problemas de rendimiento de software e incumplimientos de contrato de la siguiente forma:

Rendimiento del Software


El equipo del director de proyecto estaba conformado por ingenieros de sistemas los cuales habían realizado diferentes pruebas, pero no encontraron las causas del error de funcionalidad en el SIR. Entonces la pregunta a resolver fue ¿cuáles son las causas para no encontrar los problemas de funcionalidad con las pruebas correspondientes? el equipo sugirió contratar una entidad externa encargada de hacer pruebas de arquitectura para el SIR. Dicha entidad encontró que efectivamente los problemas no se podían solucionar con pruebas de funcionalidad, sino con simulación de carga.


El resultado de estas pruebas determinó los cuellos de botella de la aplicación y adicionalmente encontró que las aplicaciones distribuidas poseían problemas en el diseño de la base de datos. Dicha entidad realizó un análisis completo del rendimiento empleando profilers o perfiladores para especificar los cuellos de botella y encontrar que había un exceso en el consumo de memoria y de procesador.

Incumplimiento en los contratos

El equipo de proyecto decidió que la mejor alternativa sería establecer una bolsa de horas para el contratista, lo que significa que para ambas empresas existiría un contrato que les obligaría a solucionar sin dilación los problemas que se presentarán en sus horas de trabajo. De no ser así se incurriría en una falta y por consiguiente se haría una deducción a la factura del contratista.


Esto generó que el contratista fuera más cuidadoso con los costos. Adicionalmente se establecieron Acuerdos a Nivel de Servicio en los tiempos de respuesta para la Mesa de Ayuda generando que el contratista estableciera prioridades para brindar un mejor servicio. Para llevar a cabo un seguimiento de las responsabilidades del contratista el director de proyecto acordó con su equipo mediciones de desempeño y cumplimiento las cuales se hacían saber a los interesados.


De esta manera logró efectuar correctamente la planeación de los riesgos ya que estableció cómo responder a las amenazas presentes y los riesgos que pudieron presentarse. Identificó oportunidades para resolver los problemas en cuanto a comunicaciones, gestión de personal y mejora del SIRC. Como resultado tuvo una actualización del plan de la dirección general del proyecto y el éxito total de su intervención como director.

Lecciones

Las lecciones de un proyecto pueden realizarse al final del ciclo de vida del mismo. Sin embargo una sección de lecciones aprendidas puede desarrollarse en el transcurso del proyecto, es decir al terminar cada una de sus fases. Las lecciones aprendidas son un activo de los procesos de la organización y se tienen en cuenta para cada área del conocimiento (integración, alcance, tiempo, costos, calidad, recursos humanos, comunicaciones, riesgos e interesados), así como para cada grupo de proceso (inicio, planificación, ejecución, cierre, monitoreo y control) dentro de la metodología PMI.

 

En la metodología PMI cada grupo de proceso se efectúa siguiendo la dinámica planificación, gestión y monitoreo. Por lo que cada paso genera unas lecciones aprendidas que deben ser documentadas. Lo anterior hace parte de las buenas prácticas para la dirección de proyectos. A continuación se exponen las lecciones aprendidas del caso anterior.


El grupo de procesos que falló en el proyecto fue el de planeación específicamente en las áreas de conocimiento de alcance, comunicaciones, recursos humanos, comunicaciones y riesgos. La planeación del proyecto debe realizarse desde el inicio y se debe realizar de manera detallada, describiendo exhaustivamente las actividades que se llevan a cabo en cada área de conocimiento.


A pesar de que las directivas de la OSR tenían definido un plan de proyecto, los entregables no contaban con un plan de contingencia u otras alternativas para completarlos en caso de que se presentaran contratiempos y existieran sobrecostos. El plan de proyecto no estaba descrito con el nivel de detalle suficiente. Sin embargo intentaron solucionar los problemas que esto generó a través de la aplicación del estándar ITIL.


Pero aún los problemas no tenían una solución definitiva a través del Centro de Servicios en las oficinas. En ese sentido uno de los problemas de la organización era el no tener definido el alcance del proyecto. Por tanto la primera lección a aplicar en todo proyecto es realizar un plan de proyecto lo suficientemente detallado para todos los interesados. Aquí se deben involucrar los entregables de cada una de las partes interesadas en el proyecto.


En ese sentido se debe realizar un plan de gestión del alcance del proyecto como lo realizó Miguel Huertas para la OSR. En este plan se detallaron las responsabilidades de los interesados y los entregables que debían presentar. Adicionalmente el plan de gestión del alcance incluyó los límites del proyecto así como la aclaración de tareas del equipo de trabajo para desarrollar el proyecto eficazmente.


Otro aspecto que no funcionó correctamente fue la planeación de la gestión para el recurso humano. Los funcionarios no fueron capacitados en el nuevo sistema con la regularidad que ameritaba y además, no se tuvo en cuenta la opinión de los funcionarios respecto a la experiencia con el sistema de información anterior. Consecuencia de esto la OSR presentó demoras en los tiempos de respuesta, baja productividad del personal e inconvenientes en el ambiente de trabajo. ¿Cómo pudo el director de proyectos solucionar esta situación? identificando los roles, funciones y relaciones de los operarios con el SIR y cada cargo administrativo en todas las oficinas de la OSR. De igual manera estableció estrategias motivacionales para todas las oficinas de la organización para mejorar el ambiente de trabajo.


Respecto a las comunicaciones el proyecto ya presentaba inconvenientes desde sus inicios puesto que la infraestructura de la organización no podía soportar la migración de datos en todas las oficinas: unas empleaban tecnología satelital y otras banda ancha. Adicionalmente las directivas de la OSR no tenían establecido el número de canales de comunicación suficientes.


Para planear la gestión de comunicaciones, el director de proyecto y su equipo debe realizar un plan de comunicaciones que comprenda las necesidades informativas de los interesados.


El director de proyectos del caso realizó dicho plan en el que incluyó la definición de los canales de comunicación y las métricas para los mismos aplicadas en las oficinas de ciudades grandes. Para las ciudades donde la tecnología para la comunicación era satelital decidió aplicar medidas en los tiempos de respuesta al usuario para determinar las causas operacionales que las propiciaban. Tuvo en cuenta los métodos de comunicación que la organización estaba efectuando y detalló la manera en que los mensajes por medios electrónicos debían ser direccionados. De igual manera especificó el propósito de cada conferencia en las ciudades donde se llevaron a cabo.


Por otro lado, el director de proyecto debe estar en condiciones de asegurar a los interesados del proyecto que los entregables serán completados a tiempo y dentro del presupuesto estimado independientemente de los riesgos que se presenten. Por lo que el proceso de planificación de riesgos debe empezar tan pronto inicia el proyecto.


Las fases de cada proceso y toda actividad que se realice dentro del proyecto genera un grado de incertidumbre y un impacto en la planeación inicial. Los riesgos son ineludibles pero mitigables. Por tanto es pertinente llevar a cabo un plan para la gestión del riesgo. En el caso de la OSR nunca se contempló la planeación de los riesgos respecto al rendimiento del SIRC. Tampoco se tomaron medidas para el contratista en cuanto a los incumplimientos en los contratos.


Una vez identificados los problemas en cuanto a la planeación de riesgos, el director de proyecto y su equipo desarrollaron un plan de gestión de riesgos que comprendía las acciones para mitigar los problemas que pudieran presentarse en el rendimiento del software y en el incumplimiento de contratos.


Como actividad principal para evitar problemas de funcionalidad con el software se determinó llevar a cabo pruebas de sistema con profilers o perfiladores para especificar los cuellos de botella y encontrar que había un exceso en el consumo de memoria y de procesador.

Respecto a los inconvenientes con los contratos se estableció una bolsa de horas para el contratista y una deducción a la factura en caso de incumplimientos. Se trabajó de la mano con la mesa de ayuda para llegar a acuerdos a nivel de servicios y priorizar los entregables y funciones del contratista.


Finalmente se documentaron las lecciones aprendidas en cada área de conocimiento para el grupo de procesos de planificación. Se designó un responsable para establecer acciones correctivas y preventivas con el fin de no cometer los mismos errores. Llegados a este punto las lecciones de un proyecto a las preguntas ¿qué salió bien? y ¿qué no salió bien? con el fin de identificar los problemas y los elementos de los cuales un director de proyecto puede prescindir o emplear para comenzar a solucionarlos. Finalmente se estipula qué hacer para mejorar el desempeño general del proyecto y la aplicación de las lecciones aprendidas en proyectos futuros.



jueves, 18 de junio de 2020

Rita Mulcahy en Español y Otras Ayudas para Pasar el Examen PMP



Prepararse para pasar el examen de Project Management Professional  (PMP) es todo un proyecto en sí. A continuación enumeramos algunas ayudas para aquellos que quieren profundizar aún más a la hora de prepararse para presentar el examen

Rita Mulcahy en Español

Puedo que no muchos lo sepan pero desafortunadamente Rita Mulcahy falleció en Mayo de 2010. Sin embargo, su legado sigue y su libro Preparación para el Examen de PMP en Español  está disponible para las personas que quieran tener un buen material de preparación complementario. Sin embargo, es importante aclarar que el libro no acredita las 35 PDUs u horas requeridas por el PMI para presentar el examen de certificación PMP.

Simulador Examen PMP

El examen de PMP de 4 horas y tiene más de 200 preguntas y el derecho a tomarlo cuesta 500 USD los cuales no son reembolsables así que puede si al presentar el examen PMP no estas debidamente preparado pues puede ser que ester perdiendo tu tiempo y dinero. Con un simulador es más fácil evaluar el dominio de las diferentes áreas de proceso y grupos de procesos que conforman la Guía de Fundamentos para la Dirección de Proyectos (PMBoK)
Si estás buscando un simulador PMP  con preguntas de un nivel de dificultad igual a las del examen registrate grátis y prueba tus conocimientos con nuestro simulador de PMP en Español. 

lunes, 15 de junio de 2020

Evita estos 4 errores al presentar el examen PMP


La certificación PMP (Project Management Professional), es reconocida y demandada a nivel mundial, y le demuestra a los empleadores, clientes, y colegas, que un director de proyecto posee conocimiento en dirección, experiencia y habilidades para llevar los proyectos a un término exitoso. Sin embargo, lograr la certificación no es tarea fácil para aquellas personas que no cumplen con el mínimo permitido de 35 horas de formación en cualquiera de las sedes aprobadas por el PMI (Project Management Institute), además de otros requisitos importantes que se deben tomar en cuenta; también se suelen cometer algunos errores a la hora de presentar el examen, los cuales generan obstáculos para alcanzar el éxito.

 

  1. Tomarse demasiado tiempo para responder cada pregunta

 

          El examen PMP consta de 200 preguntas de opción múltiple para las cuales cuentas con 4 horas para responder. Es decir que debes intentar tomarte menos de 2 minutos para contestar cada una si deseas completar todo el examen. Algunas de estas preguntas contienen casos específicos donde tus habilidades de Project Managing son puestas a prueba, siendo estas las que requieren más tiempo para ser analizadas.

Debes administrar el tiempo sabiamente, evitar los descansos y controlar el uso del baño: el tiempo que uses para esto de igual forma será deducido de las 4 horas que cuentas para resolver el examen. Te recomendamos tener tu botella de agua cerca, de esta manera no perderás tiempo al momento de refrescarte.

 

  1. No indicar la necesidad de tomar el examen en Español

 

          Al momento de solicitar tu examen PMP al PMI con varias semanas de anticipación, existe la opción de presentarlo en Español en caso de que no domines el Inglés, puesto que este examen está en ese idioma por defecto. Para saber más, puedes verificar todas las pautas y condiciones en el Manual del PMP y tomar las previsiones necesarias, de esta manera evitas las sorpresas permitiéndote estar lo más cómodo posible para alcanzar la concentración que necesitas.

 

  1. Poca preparación

         

          El examen PMP contiene 5 dominios establecidos en el PMBOK (Project Management Body of Knowledge), cada uno prueba tu competencia en más de 20 áreas de habilidades. El examen también pone a prueba tu aptitud, entendimiento y conocimiento de cada una de las habilidades que son necesarias para los estándares de la industria de PMPs.

Las preguntas del examen son constantemente revisadas y analizadas, por eso, el contenido es altamente relevante a los diferentes casos de Project Management actuales. De las 200 preguntas, 175 son calificadas, y aquellas que se encuentren sin responder son consideradas como incorrectas. Debes tratar en lo posible de contestar todas las preguntas del examen.

Por esta razón te recomendamos desarrollar tus conocimientos al máximo (haciendo énfasis en aquellas áreas que no dominas del todo), mediante todas las herramientas a tu disposición, como simuladores del examen, grupos de estudio, lecciones y cursos. Todos disponibles en CertCampus aprobados y certificados por el PMI.

 

  1. Asumir la calificación en base al número de respuestas correctas

El porcentaje de reprobados del examen PMP es un poco alto a un 40-50% para las personas que toman el examen por primera vez. No hay un número de preguntas específicas que deben ser contestadas correctamente para ser aprobado. Cada pregunta es calificada basada en su dificultad relativa, es decir que si respondes acertadamente todas las preguntas fáciles, pero fallas en las difíciles, es muy posible que aún repruebes el examen.

No existe manera de distinguir las preguntas que son puntuadas de aquellas 25 que no lo son, lo que significa que debes dar lo mejor de ti e intentar responder todas las preguntas correctamente.

Hasta el 2005, la calificación mínima para aprobar el examen era del 61% de las respuestas correctas. Sin embargo, este ya no es el caso en la actualidad. Por el contrario, las preguntas son calificadas basadas en su dificultad, lo cual ocasiona mayor  dificultad para aprobar simplemente respondiendo correctamente a cierto número de preguntas.

El PMI asegura en su sitio web que la calificación para aprobar el examen es determinada basándose en un análisis psicométrico de las respuestas de los participantes donde demuestren su aptitud para desempeñarse adecuadamente en sus trabajos. Significa que una persona puede pasar el examen con una calificación del 60% mientras otra puede reprobar con un 65%. En otras palabras, cada examen está calificado individualmente basado en el nivel de dificultad de las respuestas correctas.

Los expertos sugieren alcanzar al menos un 80% de calificación en las simulaciones del examen, así te sentirás familiarizado con este al momento de presentarlo.

          Ahora que ya conoces los errores más comunes que debes evitar, puedes planificar con anticipación las pautas que necesitas para alcanzar el éxito en  tu próximo examen PMP.

 

¡Exitos!


lunes, 1 de junio de 2020

¿Qué Hace un Director de Proyecto PMP®?



El rol del de un director de proyecto en estas organizaciones es muy diferente al de un lider funcional o director de operaciones y la principal diferencia radica en que un director de proyecto es encargado por la organización de liderar un equipo responsable de alcanzar los objetivos del proyecto. El lider funcional es el responsable de gestionar una unidad de negocio específica tal como el departamento de recursos humanos o ventas. Un director de operaciones es responsable de asegurar que la operación cotidiana del negocio, cualquier que sea, funcione adecuadamente y sin tropiezos. 

El título de director de proyecto puede ser usado de manera muy amplia para designar a alguien con la responsabilidad de completar un proyecto. A veces la gerencia de la organización o los patrocinadores del proyecto requieren a alguien que tenga la capacidad de gestionar un proyecto pero  no desean ceder control de ciertos aspectos como por ejemplo el presupuesto, cronograma e incluso el alcance del proyecto. Mientras que el patrocinador del proyecto se empeñe en usar su influencia alterando de manera arbitraria las restricciones del proyecto deslegitima al director de proyecto y esto es una receta para el desastre puesto que al ser el responsable del éxito del proyecto el director de proyecto debe tener la autoridad y control necesarios sobre todo  el proyecto. El director de proyecto es el principal tomador de decisiones durante la vida del proyecto y como tal  el éxito depende principalmente de la efectividad de sus decisiones. Esto no quiere decir que el director de proyecto debe hacer todo el solo, simplemente él debe tener pleno conocimiento de lo que se requiere hacer, quién debe hacerlo, cuando  debe hacerse y la cantidad de recursos necesarios para hacerlo. En la metodología descrita por el PMBOK  El título de director de proyecto designa a una persona con toda la responsabilidad  y un alto nivel de autoridad respaldado por la organización que emprende el proyecto. Si al director de proyecto le falta autoridad o responsabilidad para la toma de decisiones entonces el término coordinador de proyectos puede ser mas adecuado para describir su rol dentro de la organización. Como los proyectos pueden variar en tamaño y complejidad un director de proyecto puede nombrar a  un ayudante que se designa con el nombre de activador de proyecto, al cual se le pueden delegar actividades como el monitoreo y control de las tareas realizadas. Adicionalmente el activador de proyecto puede asumir labores administrativas tales como el análisis de reportes o el manejo de la caja menor del proyecto.

Un director de proyecto hábil se mantiene al tanto de todos los aspectos del proyecto, incluso los que ha delegado.

Cualquier persona que haya tenido la experiencia de liderar un equipo sabe que  es completamente normal que surjan situaciones entre los miembros del equipo. El director de proyecto experimentado empleará sus habilidades   y talentos para manejar este tipo de situaciones las cuales deben ser confrontadas, inicialmente con el miembro del equipo y de ser necesario escaladas a la gerencia.

Es de vital importancia para el director de proyecto mejorar continuamente sus habilidades personales y de liderazgo. Habilidades como la negociación, manejo de  situaciones complejas, o motivar al equipo requieren de una dosis de inteligencia emocional y talento que son esenciales para un director de proyecto y mejorarlas continuamente debe ser la aspiración de un verdadero director de proyecto con vocación. Una señal inequívoca de un director de proyecto hábil es hacer que  su equipo coopere y actúe de manera efectiva y sin fricción.

La mayoría de empresas operan bajo una estructura organizacional funcional y por lo tanto es normal que los directores funcionales tengan los recursos y habilidades necesarias para completar el proyecto dentro de su propia unidad de negocio. Sin embargo, cuando el proyecto involucra multiples unidades de negocio se requiere la cooperación de varios directores funcionales para guiar a sus respectivas unidades de negocio con el fin de colaborar hacia el éxito del proyecto. Esta dirección formal, llamada autorización de trabajo, provee al director funcional el alcance de su labor, el cronograma de actividades e información relevante sobre el presupuesto.  Al tratar con directores funcionales el director de proyecto hábil tratará de sacar provecho de  sus habilidades interpersonales y  de negociación, puesto que la realidad es que para el director funcional el proyecto no necesariamente es una prioridad dado que él tiene su propia unidad de negocio la cual gestionar y por eso intentar lograr la cooperación del director funcional siempre es una buena idea. Incluso Puede que la oportuna colaboración del director funcional y su respectiva unidad de negocio sea crítica  para el bienestar mutuo del proyecto y su unidad de negocio  e incluso para toda la organización.

Suele ocurrir que  el patrocinador del proyecto o los interesados y la gerencia asignan al director del proyecto el cual le debe rendir cuentas al patrocinador o alguno de los interesados. Si el proyecto hace parte de un contrato entonces el director de proyecto también debe rendirle cuentas al cliente  y procurar que las necesidades e intereses del cliente se cumplan. El director de proyecto es el que tiene la última palabra sobre el envió de  solicitudes de cambios y es responsable por el manejo de las comunicaciones con el cliente y con la gerencia. El director de proyecto también hace las veces de puente entre el equipo de producción y el cliente y es altamente deseable que tenga buena experiencia en la industria en la que está trabajando puesto que debe estar en capacidad de entender y discutir las necesidades o problemas que surgan con el cliente o el equipo que ejecuta el proyecto.

AddThis