Andares de un proyecto

Las prioridades deben ser claramente vistas por el project manager y su equipo

Publicado el Enero 25th, 2012 en Seguimiento, Calidad por admin

6a00d8341bf67c53ef0154361f25a3970c-800wi.jpgTeníamos más de cien tickets pendientes por atender, éramos cuatro personas en el equipo y teníamos tres clientes al teléfono solicitando ser atendidos, todos pedían fechas de entrega y presentación de avances, algunos querían hacer cambios a sus requerimientos… hablé con mi equipo y les pedí que colgaran los teléfonos y que no contestaran ninguna llamada o correo con respecto a los pendientes. Les pedí que entráramos a una sala de juntas, cuando cerramos la puerta no tenía ni idea de lo que iba a decirle a mi equipo, en realidad yo sólo quería escapar, no tenía un plan ni nada que decirles.

Permítanme comentarles cómo es que llegamos a ese punto.

En el año 2005 trabajaba en una empresa y yo era líder de proyectos en el área de sistemas. Por los últimos años habíamos estado trabajando en la creación de sistemas que fueran automatizando toda la cadena de valor de la empresa. La estrategia de la dirección general no era adquirir un ERP (Enterprise Resource Planning es un sistema que automatiza gran parte de los procesos administrativos de una compañía) ni un CRM (Customer Relationship Management es un sistema de información para la atención a clientes), más bien parte de su estrategia era adquirir un buen sistema de facturación e integrar todos los sistemas alrededor de éste. Para esa época, ya llevábamos gran parte de los sistemas desarrollados, así que la dirección general, al ver este avance y el hecho de que el sistema de facturación nuevo estaba quedándose corto, decidió hacer la adquisición del sistema nuevo.

Yo estaba a cargo del desarrollo de algunos sistemas y cuando empezaron los esfuerzos de implementación de la infraestructura de facturación, todos los equipos fuimos dirigidos a atender de manera inmediata cualquier necesidad de integración que surgiera.

Recuerdo que teníamos un sistema en el que registrábamos cualquier petición del usuario. Allí capturábamos las necesidades del usuario y también incluíamos algunos datos como el estimado de tiempo que llevaría cada fase de desarrollo, las personas a asignar al proyecto, etc. A esto le llamábamos el sistema de tickets. Cada ticket o registro podía ser un simple cambio, un reporte o hasta un sistema nuevo.
Por más de tres meses habíamos estado trabajando en la integración con el sistema de facturación y cada vez que queríamos atender a un usuario de otro sistema, la gerencia nos pedía que dirigiéramos todos nuestros esfuerzos a la integración. Yo llegué a preguntar “entonces, si me hablan ¿les digo que no los voy a atender?” y me respondieron “sí, diles que sí tienen un problema con eso, que me llamen a mí”, eso me dio seguridad inmediata porque así yo le mandaba a mi jefe todas las llamadas difíciles, pero no sabía lo que me esperaría cuando la integración con el sistema de facturación terminara.

Cuando nos dijeron que la integración con el sistema de facturación ya no era una prioridad y que necesitaban que nos enfocáramos a los demás pendientes que teníamos, los usuarios se enteraron y se volcaron al teléfono pidiendo ser atendidos como lo mencioné al inicio de esta entrada.

Así que allí estábamos dentro de la sala con un sentimiento de culpa por no estar trabajando ni atendiendo a los usuarios. Yo había escuchado como uno de los miembros de mi equipo estaba hablando desesperado con un usuario que ya lo había llevado al límite de su paciencia, así que preferí que no atendiéramos llamadas en vez de atenderlas mal.

Lo primero que les dije fue: “no podemos atender a todos al mismo tiempo, necesitamos atenderlos uno por uno y dejarles saber que vamos a atenderlos a todos a su debido tiempo”. Nos dividimos la lista de usuarios y les llamamos. Les hicimos saber que no íbamos a atender detalles sobre sus proyectos en esa llamada, ni íbamos a darles fechas en ese momento, pero que desde ese mismo día empezaríamos a hacer los pronósticos y a priorizar nuestra lista de tickets para atenderlos lo más pronto posible.

prioridades.jpg Al día siguiente revisé todos nuestros tickets (proyectos en potencia). Muchos eran errores de funcionalidad de nuestros sistemas, así que  les di la mayor prioridad. Visité a los interesados (quienes habían abierto el ticket) y les pedí que me mostraran el error, algunos de los errores no se presentaron, lo que me dio a entender que probablemente había sido un error de la plataforma tecnológica y no de nuestro sistema. Estos tickets los rebajé de prioridad y me quedé con el resto. Asigné a cada miembro de mi equipo una cantidad igual de tickets para atender, pero después de unos días casi todos los tickets seguían abiertos y sin conclusión. Cuando les preguntaba por qué no estaban atendiendo los tickets, me decían cosas como: “ah!, es que no me acordaba de ese ticket” o “ah!, no sabía que tenía mayor prioridad que el que estoy atendiendo”.

Me puse a pensar y llegué a la conclusión de que la lista de tickets era abrumadora y que si la veíamos como un todo, no detectábamos progreso aún cuando se cerrara uno o dos diariamente.

Así que al otro día pedí tres blocks de notas auto adheribles (PostIt®) de diferentes colores y tomé uno de ellos, el color amarillo. Tracé unas líneas en el papel para dividirlo en varias secciones, que contendrían lo siguiente:

  • Folio del ticket
  • Fecha de captura
  • Prioridad
  • Descripción del problema
  • Nombre del usuario
  • Nombre del ingeniero asignado
  • Fecha de cierre

Imprimí la lista de tickets ordenándola por persona asignada para atenderlo (ingeniero asignado) y le di a cada miembro de mi equipo su parte. Les pedí que llenaran cada PostIt con la información de cada ticket que les estaba dando y que lo revisaríamos a fin de día. Al final del día, cada miembro del equipo tenía alrededor de 30 PostIts amarillos en sus manos, con la descripción de cada ticket asignado a ellos.
Dividí la pared de mi lugar en dos partes: la izquierda y la derecha. Les pedí que ordenaran descendentemente por orden de antigüedad los PostIts de izquierda a derecha y de arriba hacia abajo, de tal forma que el ticket más a la izquierda y más arriba fuera el más antiguo y el de más abajo y más a la derecha fuera el más nuevo.

También les pedí a los miembros de mi equipo que cada vez que atendieran un ticket y que lo cerraran, movieran su PostIt de la parte izquierda de la pared a la parte derecha. Al final de la semana revisábamos en una reunión cuál era el status de cada ticket y re-priorizábamos la lista de acuerdo con la retroalimentación de los usuarios y de la gerencia. En esa misma junta reconocíamos la labor de cada miembro del equipo y hacíamos mención especial de aquel que hubiera cerrado más pendientes durante esa semana. Esto provocó un sentimiento de competencia positiva en la que los compañeros querían cerrar tickets.

Al final del mes agregamos color a la pared. Todos los tickets levantados en ese mes se vaciarían sobre PostIts de color verde. Cuando los PostIts verdes empezaron a dominar, un papel color amarillo era vergonzoso en la parte izquierda de la pared, porque significaba que era un pendiente antiguo que no había sido atendido. Al final del mes cambiamos a papeles de color rosa y así sucesivamente.

El ambiente que provocó esto entre mis compañeros fue muy positivo. Cuando otros compañeros de otros equipos preguntaban qué era eso que estaba en mi pared, ellos les decían “es el muro de los lamentos” haciendo referencia a la dificultad que representaba cerrar algunos tickets y lo vergonzoso que era tener pendientes aún abiertos allí (lo anterior, desde luego, con todo respeto para los miembros de la comunidad Judía entre mis lectores).

mural1-post-it.jpg

Fue impresionante ver que el número de tickets se redujo a 20 en las primeras semanas, el equipo de proyecto estaba motivado y colaborando unos con otros, los usuarios dejaron de hacer llamadas y la productividad de nuestro grupo se elevó impresionantemente.

Mi conclusión es que lo que no se ve, no se atiende. Actualmente contamos con excelentes sistemas de manejo de pendientes, agendas electrónicas y todo tipo de dispositivos tecnológicos que nos apoyan a tener una vida mejor administrada, pero la verdad es que la mayoría de nosotros atendemos día con día lo más urgente y lo que tenemos a la vista.

No estoy en contra de estos dispositivos, sino que creo firmemente en que tenemos que llegar a un punto en el que los sistemas y los dispositivos trabajen eficientemente para nosotros, quizás haciendo un tiempo diariamente para organizar nuestra lista de pendientes y re-priorizarlos.

Como quiera que sea, la “operación PostIt” siguió aún algunos meses después que yo dejé la compañía para trabajar en otro lado. Mi último día en la compañía el número de pendientes en el lado izquierdo de la pared no llegaba ni a diez… y todos eran del color del mes en curso.

Por Fernando Valdez

Planeando el año nuevo

Publicado el Diciembre 12th, 2011 en Planeación, Tiempo, Alcance por admin

reloj_ano_2012.jpgYo soy un planeador. Disfruto planear. Disfruto crear escenarios en mi mente y establecer rutas por las que debiera/pudiera desarrollarse un proyecto. La planeación se me facilita, surge de mi mente sin esfuerzo, empiezo visualizando el futuro y entonces empiezan a saltar los detalles… es como una fiesta de ideas, consideraciones, riesgos, métricas, iniciativas, colores, sensaciones… y al final, vislumbro el éxito, la “ceremonia de premiación”, palpo el premio en mis manos y pienso hasta dónde lo voy a colocar… Puedo documentar detalles de cada plan, puedo agendar cada detalle y hacer planes secundarios por si el original no funciona. Al final, un hermoso plan, lista de recursos necesarios y planes subsidiarios al máximo nivel de detalle… y es aquí cuando es necesario empezar a ejecutar. Ejecutar, esa es otra historia completamente diferente.

Las diferencias de planear y ejecutar

No es necesario que aborde el tema de las diferencias entre planear y ejecutar, éstas son obvias para los avezados lectores. Más bien quiero mencionar las diferencias en la perspectiva de planear y la de ejecutar.

Ejecutar es hacer realidad el plan. Si bien es cierto que el plan pocas veces puede ejecutarse exactamente como fue creado, es decir, sin cambios, también es cierto que muy pocas cosas importantes se han logrado en el mundo sin un plan. La planeación es necesaria y lo es más en un proyecto. Ejecutar es realizar las actividades que crearán los beneficios tangibles del proyecto.

Conozco excelentes ejecutores y quiero traer a colación a un ex jefe que tuve hace algunos años. Este individuo era muy eficiente, todo el tiempo estaba haciendo cosas que hicieran avanzar los proyectos. Dada su gran experiencia mucho de lo que hacía le salía bien. Los proyectos que el administraba eran ráfagas de esfuerzo coordinado entre los miembros de su equipo. Era necesario tener una mentalidad ágil y acostumbrarse a los cambios para poder pertenecer a su equipo, porque en un solo día podía cambiar la dirección del proyecto casi diametralmente. En una ocasión, en un proyecto mediano nos distribuimos las tareas y a mí me tocó construir una parte muy complicada de los entregables. Cuando me acercaba al final de las tareas y durante una revisión de los avances mi jefe cambió tanto el diseño del producto que era casi imposible reutilizar todo lo que ya se había elaborado. Por otro lado él estaba muy descontento con el lento progreso de los avances y empezaba a atribuir el rezago a la lentitud con la que se estaban construyendo los entregables. Cuando me di cuenta que caminábamos “dentro de una cueva sin luz”, dando palos de ciego, le pedí que me describiera cuál era el plan, a lo que me contestó “el plan es que termines lo que estás haciendo y lo hagas rápido”… este individuo no tenía un plan. El plan era ejecutar. Hacer, hacer y hacer, y cuando encontráramos un resultado indeseado, cambiar de dirección. Esto era prácticamente la técnica de prueba y error.

Mi ex jefe alcanzó muchas metas gracias a su determinación por completar tareas, sin embargo los recursos desperdiciados y el desgaste del equipo eran enormes.

Hago lo que me gusta

Hacer un plan es crear un mapa del terreno que se desea andar. Si lo miras con detenimiento bien podrías concluir que la planeación no genera ningún entregable utilizable por el usuario final y tienes razón. En lo personal, yo invierto mucho tiempo y disfruto planeando y proponiendo escenarios ideales para el desarrollo de un proyecto, pero en el momento de la ejecución preferiría que alguien más hiciera las cosas. Hasta en lo personal pagaría por tener a alguien ejecutando mis planes: haciendo mis llamadas telefónicas, enviando mis paquetes por correo, recogiendo los boletos, etc.

En cambio, sólo me gusta hacer aquello que disfruto haciendo. Acudo a la ley de terminar primero lo más divertido, lo que me da alguna satisfacción o incluso lo que pudiera terminar más pronto, pero seamos honestos, crear algo que valga la pena normalmente viene de la mano con realizar algunas tareas que no son muy agradables. Conocí a una persona que decía: “Me gusta solamente el 50% de las actividades de mi trabajo, pero no puedo sólo hacer la mitad de ellas. Para conservar mi trabajo necesito hacerlas todas y cuando hago aquellas que no me gustan pienso que vale la pena hacerlas por el sólo hecho de hacer las que si me gustan”. En los proyectos esto aplica también, es decir, ¿quién disfruta escalando a un miembro ocioso, asistiendo a muchas juntas, reportando avances cuando se va retrasado en el proyecto o recibiendo cambios al proyecto cuando se ha llegado a un nivel decente de avance?

team-photo-6-06-fun-one.jpg La planeación necesaria para año nuevo

Las personas solemos ponernos metas cotidianamente en las diferentes dimensiones de nuestra vida. Metas personales, de salud, económicas, laborales, sociales, etc. Algunos aprovechan el inicio de año para llamar a estas metas sus propósitos de año nuevo. Dichos propósitos suelen ser serios estatutos de aquello que se desea o se requiere alcanzar. En lo personal creo que los propósitos son el reflejo consciente de que necesitamos hacer algunas cosas en nuestra vida que no disfrutamos, porque si disfrutáramos haciéndolas ya las habríamos empezado y hasta terminado.

Algunas otras si las disfrutamos, pero conllevan esfuerzos que no estamos dispuestos a hacer, por ejemplo, salir de vacaciones. Definitivamente la mayoría querríamos unas largas vacaciones en un destino específico, pero no lo hemos logrado no por falta de interés, sino porque para lograrlo necesitamos ahorrar y es allí donde se encuentra la dificultad porque se requiere un cambio en las costumbres financieras personales y familiares.

Lo mismo ocurre en las organizaciones y en los proyectos. Necesitamos planear para diversas oportunidades que nos depara el año entrante. Estamos de cara a un año electoral en México, en otros países de Latinoamérica y en la superpotencia mundial, los Estados Unidos, y esto puede afectar directa o indirectamente a nuestros proyectos. También se ha pronosticado un crecimiento menor para el año siguiente a diferencia del que se tuvo durante el 2011, esto puede afectar también a los planes de inversión de nuestras compañías.

Los factores macro y micro económicos, los factores ambientales, los factores sociales, todo suma cuando se prepara para los proyectos. Un cambio de año es un hito que muchos utilizan para iniciar cosas nuevas, para cambiar una política de proveedores, para eliminar ciertos gastos, para incrementar algunas medidas de seguridad, etc. Todo esto pudiera afectar positiva o negativamente a nuestra organización, portafolio y/o a nuestros proyectos.

Planear todos los días como si fuera año nuevo

¿Has estado postergando alguna actividad? Es necesario respetar los hitos de nuestros proyectos y de nuestra vida en general. Si lo vemos fríamente, el cambio de año es solamente una cuestión de números en el calendario. Necesitamos planear considerando los riesgos que se avecinan y ejecutar diligentemente las actividades planeadas a menos que tenga más sentido eliminarlas del plan.

En la empresa para la que trabajo ya tenemos el plan de liberación de sistemas para los años 2012 y 2013. Ya sabemos qué fines de semana necesitaremos trabajar extra para hacer posible que los clientes cuenten con las nuevas versiones de nuestro sistema. Esto no quiere decir que no necesitaremos alguna fecha adicional o que no podremos cambiar tales fechas si es estrictamente necesario, pero ya tenemos una guía, un mapa, una idea de cómo pinta el próximo año.

Te invito a reflexionar sobre los factores que podrían influir en tu toma de decisiones el próximo año y a realizar las actividades que consideres necesarias para ampliar las posibilidades de éxito en tus proyectos. Este es un buen momento, aprovéchalo y sitúate por encima de las cosas.

Por Fernando Valdez

Historias de contratación de personal para los proyectos

Publicado el Noviembre 16th, 2011 en Recursos Humanos, Comunicaciones por admin

268992_illustration.jpgAunque entiendo que este es un espacio de líderes de proyecto, también entiendo que en varios países nuestros líderes de proyectos desarrollan funciones de manejo de personal como contratación, autorización de vacaciones, etc. Por eso quisiera compartir con ustedes experiencias y lecciones aprendidas con respecto al reclutamiento, la selección y administración del personal.

El caso de las mentiras en la entrevista

Hace ya varios años yo trabajaba en el departamento de desarrollo de sistemas de un banco y un compañero al que llamaré Juan, me dijo que había acudido a una entrevista de trabajo, pero que no tenía el perfil requerido por el puesto. Juan se lamentaba por los beneficios que se le habían ido de las manos por no cumplir con el perfil. Poco después Juan me comentó que había ido a otra compañía a ofrecer sus servicios y que en esta ocasión si había tenido éxito. Cuando le pregunté de qué se trataba el trabajo me explicó que tendría que administrar una plataforma IBM así como operar parcialmente la base de datos (DB2) y desarrollar algunos scripts para obtener información de la misma. Me pareció extraño que Juan hubiera sido aceptado para ese puesto porque yo lo conocía y sabía que el no tenía esa experiencia, entonces le pregunté “oye, y ¿sabes hacer todo eso?” y el me contestó “no, de hecho estoy un poco preocupado. No sé como vayan a reaccionar cuando se enteren que les eché mentiras en la entrevista…”

Juan tenía un grave problema de ética, pero el problema mayor radicaba en aquellos que lo seleccionaron para ingresar a la compañía sin comprobar de alguna forma que el candidato tuviera las habilidades necesarias para desempeñar su puesto. Necesitamos ser muy cautelosos al entrevistar personal, sin caer en el extremo de ser groseros con el mismo. Por cierto, Juan entró a trabajar en aquella compañía y lo despidieron en dos semanas, después de ese fracaso no acumuló mucho currículum en otras compañías formales de la zona.

El caso de las promesas incumplidas

Apliqué para ingresar a trabajar en una empresa y fui seleccionado como un candidato factible. En el paquete de prestaciones me prometieron que me darían un bono anual equivalente al 10% de mi sueldo anual liquidable en el mes de noviembre de cada año. Hice mis cuentas e incluí este bono como uno de los ingresos fijos anuales y dado que me convenía, decidí aceptar la oferta y cambiarme de trabajo. Poco antes de ingresar a la compañía me llamaron para firmar un acuerdo de contratación, así que fui y cuando llegué el reclutador dijo que sólo se trataba de un formalismo y que lo que decía el acuerdo era exactamente lo que habíamos discutido antes.

El reclutador se mostró muy hablador mientras yo revisaba los papeles, así que no puse toda mi atención en lo que estaba a punto de firmar. Finalmente firmé y me retiré. Llegó mi primer día de trabajo y acudí a la empresa donde por un lapso de tres meses hice mis mejores esfuerzos por sobresalir y cumplir mi parte del trato. En ese momento llegó el tiempo de la liquidación de bonos y me surgió la duda de si me pagarían un proporcional de aquel bono y fue cuando el gerente de recursos humanos me visitó y me pidió hablar aparte. En su mano traía algunos papeles y enseñándomelos me preguntó ‘¿este es el documento que firmaste tú hace unos meses?”, yo asentí y entonces me dijo “éste es tu contrato y si revisas bien, en este documento no aparece un bono anual”. Yo le expliqué lo que había ocurrido y me dijo que no podía hacer nada al respecto.

img_como_tengo_que_hacer_el_contrato_de_un_servicio_7432_orig.jpg Fue un error de mi parte haber firmado el documento dejándome distraer por aquel reclutador con poca ética, sin embargo una compañía debe cuidar estos detalles ya que impactan directamente en la credibilidad general de la compañía y de sus empleados. Algunos reclutadores son meros vendedores (sin menospreciar la valiosa labor de éstos) que buscan una comisión por el trato pactado, pero tanto en el caso de los reclutadores como de los vendedores debe haber ética para no comprometer a la compañía a ofrecer lo que no están dispuestos a cumplir. Por cierto, me enteré de que el reclutador que me contrató creó una base de datos con información de nuestros empleados, renunció y se la llevó. Poco tiempo después cada persona que laboraba en mi departamento recibió una llamada de este reclutador invitándolos a dejar nuestra compañía para ingresar a otra.

Las referencias laborales ignoradas

Un miembro problemático de mi equipo al que llamaré Pedro había estado criticando la forma en que administrábamos la organización y “la gota que derramó el vaso” fue su actitud visiblemente grosera durante una reunión de departamento. Terminando nuestra junta le pedí un momento a solas para conversar sobre su actitud y el me comentó todo lo que pensaba.

Pocos días después me reuní con gerentes y directores del departamento porque se estaba presentando una dificultad financiera y necesitábamos dar de baja a un miembro del equipo. Después de revisar el desempeño de cada uno de los miembros determinamos que quien tenía el desempeño mas bajo era Pedro. Llegado el día dimos de baja a Pedro y dejó de ser un problema.

Poco después una reclutadora de nuestra empresa me contactó para preguntarme si Pedro había trabajado conmigo ya que necesitaba referencias para llenar una posición para la que Pedro parecía bien calificado. Yo le comenté acerca de su desempeño y de su actitud y dejé que la reclutadora tomara la mejor decisión, ella se mostró decepcionada al escucharme ya que pensaba que había encontrado al candidato ideal. Poco después alguien de mi departamento me comentó que se había encontrado con Pedro quien había ingresado a la compañía en la posición por la que me solicitaron referencias.

Mi unidad de negocio no se vio afectada por tal contratación, sin embargo estoy seguro que la compañía sufrirá por individuos como Pedro dentro de la ella gracias a un consejo no escuchado. La reclutadora cumplió con su “cuota de contratación” y echó el problema a otro lado. Ese era un problema ya resuelto que resultó ser un nuevo problema para la compañía.

Información equivocada de la fuente equivocada

En una ocasión abrimos una posición nueva en la empresa y, después de evaluar muchos candidatos, encontramos uno con todas las características que necesitábamos. Cuando le hicimos la oferta económica se mostró interesado. Más adelante la reclutadora me informó que el candidato a quien llamaré Javier, había aceptado nuestra oferta.

Pasó un par de meses y un día Javier me pidió hablar en privado. Me dijo que en su proceso de reclutamiento había habido un mal entendido, dijo que la reclutadora le había informado mal acerca del porcentaje de impuestos que le iban a quitar y que su sueldo neto estaba muy por debajo de lo que el esperaba. Yo le pregunté a Javier qué dato le había dado la reclutadora y me dijo que le había dicho que le quitarían sólo el 5% de su sueldo por concepto de Impuesto Sobre la Renta (ISR). Le pregunté si antes había tenido un trabajo de planta y me comentó que no, de tal forma que le expliqué que cuando se trabajaba de planta el porcentaje de descuento por concepto de impuestos no podía ser menor al 30%, y que desde luego la reclutadora no era una autoridad para proporcionar esa información. Le dije que lamentaba la confusión y que iba a ver la posibilidad de hacer algo al respecto. Mis superiores coincidieron en que no había presupuesto para incrementos y que la breve permanencia de Javier no ayudaba para evaluar si valía la pena aumentarle el sueldo. Javier, se desmotivó al escuchar la noticia y al poco tiempo se retiró de la compañía.

smarter-procurement.jpg Perdimos un buen elemento y gastamos tiempo y dinero en capacitación y en todos los esfuerzos de reclutamiento y selección de personal, sólo porque la persona equivocada dio información equivocada sin tener autoridad para darla.

La autorización no autorizada

En una ocasión abrimos una posición para la que recibimos muchos candidatos. Después de un par de entrevistas con diferentes personas decidimos avanzar en el proceso con uno de los ellos y, de acuerdo con el proceso de reclutamiento, solicité que se elaborara una propuesta económica.

El procedimiento dictaba que una vez hecha la propuesta, ésta me debía ser enviada para conseguir las autorizaciones y poder extenderla al candidato o rechazarla y volver a elaborarla. Sin embargo, por experiencias anteriores en las que el departamento de reclutamiento se había tardado mucho tiempo en llenar nuestras posiciones, ellos consideraron que sería buena idea dar dos pasos en un solo golpe y me enviaron la propuesta para autorización al mismo tiempo que se la extendían al candidato. Yo la revisé y la autoricé y se la envié al manager funcional en Estados Unidos para ser aprobada. Sin embargo, el manager de USA me comentó que detuviera el proceso porque el proyecto para el que estábamos buscando personal se había cancelado.

Hablé con el personal de Reclutamiento sobre la situación y rechacé la propuesta y solicité cerrar nuestra posición, a lo que el gerente del departamento me contestó que no era posible rechazarla y que necesitaba reclutar al candidato, porque ellos ya le habían extendido la propuesta. Le comenté que yo nunca había autorizado ninguna propuesta y descubrí que ellos se habían saltado ese paso del proceso para agilizar las cosas.

El gerente del departamento de reclutamiento me dijo que ellos sólo estaban tratando de darnos un mejor servicio, y yo le comenté que le agradecía la intención pero que era su obligación servirnos ágil y eficientemente siempre a todos los departamentos y sin favores especiales, y que no debía saltarse pasos de su propio proceso. El respondió un tanto molesto pero aceptando que el error se había cometido en su departamento. Desde entonces cuando lo veo gasto un saludo todas las mañanas y soy correspondido con una mueca parecida a una sonrisa apretada.

Conclusión

Puedo continuar con experiencias vividas, pero creo que he llegado al punto que quería destacar: el personal que contratas es demasiado importante como para dejarlo en manos de desconocidos. Si tu departamento de selección y reclutamiento es efectivo, te felicito, pero si compartes alguna experiencia parecida a las descritas arriba, te recomiendo que te involucres activamente en la selección de tu personal. Asegúrate que tus candidatos están bien informados del tipo de empresa en la que podrían estar trabajando. Ayúdalos a entender detalles acerca de la frecuencia de su pago, la cantidad libre que estarán recibiendo, los horarios, las flexibilidades que maneja la empresa así como aquello en lo que no se flexibilizarán. En resumen, ayúdalos a evitar sorpresas, después de todo esto es un área que un project manager debe desarrollar dentro de sus proyectos.

Por Fernando Valdez

¿Cuál es la mejor herramienta del Líder de Proyectos?

Publicado el Septiembre 21st, 2011 en Documentación, General por admin

herramienta_ejecutivo.jpgTodos necesitamos de herramientas para desarrollar un trabajo específico. Los médicos tienen su instrumental, los carpinteros tienen sus herramientas y el caso de los Líderes de Proyectos no es muy diferente.

Me he encontrado diferentes respuestas a la misma pregunta mientras entrevisto a candidatos para ocupar una posición de líder de proyectos, algunos opinan que un sistema para creación y control del cronograma tal como Microsoft Project o Primavera son esenciales dentro de la caja de herramientas de un Project Manager, otros se conforman con Microsoft Excel, algunos son más sofisticados y dan una lista de acrónimos de lo que probablemente sean sistemas de código abierto para la asistencia en la labor de administración del proyecto.

La realidad es que no hay una respuesta única para esta pregunta, eso va a depender de la complejidad del proyecto, de los estándares de la organización en la que se desarrolla el proyecto y en última instancia de las preferencias y experiencia del Líder del Proyecto.

El que es martillo…

Cuando una persona es buena utilizando una herramienta, normalmente quiere utilizarla para todo lo que se le pone enfrente. Hace muchos años tuve un jefe que quería que hiciéramos un sistema para el departamento de servicio a clientes en Microsoft Access. Cuando le dije que las capacidades visuales de esa herramienta no eran muy poderosas me dio una cátedra de cómo si lo eran. Después le argumente que necesitaríamos que los datos fueran almacenados en un servidor al cual se conectaran todos los agentes para usar, actualizar y agregar información, a lo que él respondió con otra cátedra de cómo hacer que aquella base de datos, que está pensada para trabajar monolíticamente (base de datos + interfaz de usuario) podría ser usada también en el esquema que necesitábamos. En fin, haciendo la historia corta esa pudo haber sido mi capacitación más rápida y completa en esa herramienta. Terminé convencido de realizar el sistema con esa herramienta de manera temporal, mientras realizábamos el sistema a más grande escala.

La moraleja de esta experiencia es que el que es martillo a todo le ve cara de clavo. En el terreno de la administración de proyectos sucede igual, cuando dominamos una herramienta creemos que todo puede realizarse con ella.

Entonces… ¿que usar?

La elección de la herramienta, como lo mencioné antes, debe obedecer a aspectos como los estándares usados, el tamaño del proyecto y la preferencia del administrador del proyecto, sin embargo sí podemos hablar de algunas herramientas básicas que pudieran ser útiles independientemente del proyecto en el que se trabaje.

Las dos herramientas

La existencia de un líder de proyectos en una organización revela la estructura de la compañía: una compañía que implementa proyectos internos requerirá tarde o temprano de una base de datos con la información de esos proyectos. Algunos le llaman “base de datos de proyectos”, otros le llaman “pipeline” (tubería por donde entran los proyectos) o simplemente portafolio de proyectos.

La primera herramienta necesaria es un sistema en el que se pueda administrar esa lista. Puede ser una hoja de cálculo con los datos relevantes de cada proyecto o un sistema hecho en casa en el que se permita modificar el status, capturar detalles, anexar documentación y otras tareas útiles para el seguimiento y registro de un proyecto.

En la compañía en la que trabajo manejamos el Rational Clear Quest, que es un sistema adaptado a nuestras necesidades para la administración de requerimientos, generación de estimados, seguimiento de entregables, registro de fechas planeadas y reales y para reporteo.

Cuando la lista de proyectos esta almacenada permite su revisión, evaluación, priorización, arranque, cancelación, etc.

La segunda herramienta sirve para el trabajo diario de un líder de proyecto. ¿cuáles son las actividades que un líder de proyecto realiza de manera cotidiana? Si me preguntan a mi yo daría la siguiente lista:

  • Seguimiento a fechas importantes
  • Seguimiento a construcción de entregables
  • Comunicación de novedades a miembros del equipo
  • Comunicación de novedades a la gerencia
  • Revisión y administración de los riesgos
  • Administración de la lista de problemas
  • Pronosticar fechas de fin de etapa y del proyecto
  • Etc.

Si se trata de un líder de proyectos más involucrado en asuntos técnicos, entonces la lista crece enormemente, porque además tendrá que lidiar con las tareas específicas de cada profesión.

La herramienta más flexible que puedo nombrar para este efecto es una hoja de cálculo.

Recuerdo que cuando entré a trabajar en mi actual compañía la oficina de proyectos estaba muy bien establecida y el seguimiento y reporteo se daba con una combinación de Microsoft SharePoint y Microsoft Excel.

La hoja en Excel era una verdadera pieza de arte. En la primera hoja se podía ver un resumen de los proyectos asignados al Administrador del Proyecto con información relevante como el centro de costos a ser cargado, estimado de horas, fechas de los milestones principales, etc.

A partir de la segunda hoja incluía una hoja por cada proyecto al que se le estaba dando seguimiento. Al lado izquierdo venia una lista del personal asignado al proyecto y el tiempo que actualmente había invertido en el mismo (esto lo obtenía Excel ejecutando una consulta de la base de datos de horas invertidas en cada proyecto). De lado derecho incluía una tabla que indicaba el tiempo planeado vs. el tiempo real invertido en las diferentes fases del proyecto, la varianza entre los valores anteriores, el estimado de tiempo para completar el proyecto (ETC), el estimado de horas finales totales (EAC) y la varianza en horas finales totales vs. lo planeado (VAC). Esta sección incluía una serie de banderas de colores que cambiaban automáticamente haciendo muy fácil determinar si una fase estaba en problemas o no.

Parte de esta hoja se llenaba automáticamente con información de otras bases de datos y algunas celdas permanecían disponibles para que el administrador del proyecto actualizara algunos valores de acuerdo con lo pactado esa semana (por ejemplo, un estimado podía variar si se autorizaba un cambio en el proyecto).

Al punto al que quiero llegar es que esta herramienta era todo lo que necesitábamos para llevar el seguimiento y para generar los reportes del avance del proyecto.

Con estas dos herramientas: un sistema de administración del portafolio y una hoja de cálculo, podíamos controlar la mayoría de la información que generaba el proyecto. Desde luego que, aunándolo a una buena aplicación para dar presentaciones y el SharePoint, nuestras necesidades quedaban satisfechas totalmente.

Además…

Actualmente poseo una licencia de un sistema llamado WBS Chart Pro y otra licencia del mismo proveedor (Critical Tools) llamada PERT Chart Expert. Ambas herramientas son económicas (199 USD cada una), muy fáciles de usar y proveen de posibilidades gráficas para representar las fases, entregables y actividades de un proyecto y su relación de jerarquía y dependencia integrándose ampliamente con Microsoft Project completando así una experiencia muy agradable y útil en la administración de mis proyectos.

Lo más importante es dominar tus herramientas

Quizás lo más importante dentro del vasto mundo de herramientas para un Líder de Proyectos sea dominar las herramientas cualesquiera que sean. Comúnmente entrevisto Project Managers que se pronuncian como usuarios intermedios de Microsoft Project y nunca han hecho un baseline, no saben forzar una relación finish-to-finish ni saben interpretar el reporte de Resources Usage que genera esa herramienta. No critico a tales individuos, solo quiero justificar mi comentario en el sentido de que necesitamos dominar al menos una herramienta a un nivel muy aceptable para que al momento de necesitar explotarla, esta nos proporcione lo que necesitamos sin mayores contratiempos. Mi esposa con frecuencia dice que “la tecnología debe trabajar para nosotros, porque una tecnología a la que hay que invertirle muchas horas para que haga lo que se supone que debe hacer, es una tecnología que no sirve, puesto que nos esclaviza y se supone que nosotros somos los amos y no los esclavos”. Estoy totalmente de acuerdo con esto en el sentido de que ya tenemos mucho de qué preocuparnos como para que la tecnología y las herramientas sean otro punto de preocupación.

Mi más atenta invitación a todos para adoptar sus propias herramientas y ponerlas a funcionar. Inviertan tiempo y dinero leyendo un buen libro que les muestre el funcionamiento total de la herramienta que hayan elegido, será tiempo y dinero bien invertido.

Por Fernando Valdez

El outsourcing en los proyectos… ¡Hay que atreverse!

Publicado el Agosto 31st, 2011 en Planeación, Adquisiciones, Costos por admin

outsourcing.jpgEn las experiencias que día a día recordamos, abundan aquellas en las que el alcance o el tiempo eran el actor principal. Platicamos como nos debatíamos para lograr cerrar la lista de requerimientos o cómo el tiempo era un factor clave para alcanzar los objetivos. En muchas ocasiones también recordamos experiencias valiosas donde el riesgo fue el factor que nos dio más problemas.

Sin embargo hay otras áreas de la administración de proyectos que también han dejado lecciones aprendidas muy valiosas y que no es común que recordemos porque se trata de temas poco ejercitados. Por ejemplo, normalmente no hablamos de contratos dentro de nuestros proyectos y es natural porque no es un área que, como el alcance, el tiempo, la calidad o el riesgo, todos los proyectos involucren.

Muchas empresas se valen de sus propios recursos (humanos, materiales, etc.) para ejecutar sus proyectos y pocos hacen uso de entidades externas que apoyen a la consecución de sus objetivos. Claro, existen algunos países y algunas empresas que si han desarrollado un habito y hasta una preferencia por subcontratar otras compañías para elaborar algunos de los entregables del proyecto.

Pero vamos desde lo mas básico: cuando un proyecto tiene riesgos (lo cual todos tienen en un cierto grado), nosotros podemos aceptarlos, mitigarlos o transferirlos. Cuando hablamos de transferirlos nos referimos a que le pagamos a otra compañía para que ellos adopten el riesgo y nosotros librarnos de esa carga (elaborar un plan de contingencia, hacer una reserva en el presupuesto para afrontar los gastos en los que incurramos en caso de que el riesgo se convierta en una realidad, etc.). Por ejemplo, un seguro de daños implica contratar una compañía aseguradora para que se haga cargo de las reparaciones en caso de un desastre. Esto implica un contrato.

Por otro lado, supongamos que nos han asignado a un proyecto de construcción y que nos encontramos en la etapa de elaboración de detalles, y dentro del plan de trabajo se requiere elaborar algunos acabados que requieren un material que nuestro equipo no esta acostumbrado a trabajar y que requiere cierto nivel de experiencia para su manejo y tallado, como por ejemplo el mármol. Podemos intentar involucrar a miembros de nuestro equipo para que hagan el trabajo, pero corremos el riesgo de echar a perder el material y/o que el cliente quede insatisfecho. Por otro lado, podemos recurrir a una compañía de gente que se encargue de trabajar profesionalmente el mármol y establecer un contrato especificando el nivel de calidad, el tiempo de entrega, etc. Esto se puede administrar como un sub-entregable del proyecto completo. Cuando la compañía especialista termine de hacer el trabajo, simplemente salen del ‘escenario’ y se concluye dicho contrato.

En una ocasión fui invitado a liderar un proyecto de alto nivel, el sponsor del proyecto era el hijo del dueño de la compañía y el producto que deseaba elaborar era un portal de Internet con características muy similares a otros que ya ofrecían el mismo servicio (ya había un estándar en el mercado).

Dado que la orden vino “de arriba” tuvimos que atender el requerimiento como urgente, pero todos nuestros recursos humanos estaban asignados a proyectos con prioridades establecidas, de tal forma que no teníamos a nadie para desarrollar el portal, y fue así que me estrené en la búsqueda de proveedores de desarrollo de sistemas que ofrecieran el mayor valor en su propuesta. Hice una matriz con la funcionalidad que requeríamos y la anexé a un documento RFP (request for proposal) para distribuirlo entre cuatro consultorías locales de prestigio.

Las consultorías tomaron el documento que estaba disponible en formato impreso y en formato electrónico y empezaron a evaluar nuestras necesidades. Yo establecí un marco de tiempo de dos semanas para que ellos revisaran la funcionalidad que solicitábamos y que hicieran su propuesta tecnológica, de tiempo y de costo. Durante las dos semanas siguientes invité a los proveedores a dos sesiones de preguntas y respuestas en las que nos pudieran hacer preguntas de cualquier detalle que consideraran relevante. Nunca nos reunimos a solas con una compañía, siempre hicimos todo público para evitar cualquier sospecha de preferencia de alguno de los proveedores y para que las preguntas de unos sirvieran para que otros tuvieran mas información. Al cabo de las dos semanas recibimos tres propuestas y una carta de abandono del proyecto.

Con las tres propuestas en mano hicimos una sesión para que cada uno de ellos explicara su solución mostrándonos las razones por las que ellos representaban la mejor opción. Después de estas sesiones y las retroalimentaciones que les dimos durante su presentación, les dimos la oportunidad de hacer una ultima revisión a su propuesta y entregarnos la que sería su versión definitiva de la solución.

Posteriormente y junto con otro colega elabore un documento que presentaría a la dirección general para la evaluación del proyecto. En dicho documento anexe las tres propuestas evaluadas desde la misma perspectiva (comparando manzanas con manzanas, para eliminar debilidades y ventajas a ese nivel) y después en la sección de recomendaciones anexé el detalle de las ventajas de cada proveedor y las desventajas. Mi colega agregó información muy importante relativa a la inversión que necesitaríamos en equipo para albergar el portal (servidores, cableado, racks, etc.) y completó su información con un par de cotizaciones.

En la sección de inversión monetaria elaboré un cuadro resumiendo los costos por concepto de desarrollo de sistemas, costos de equipo, mantenimiento anual y otros costos relacionados, así como el plan de pagos de cada una de las compañías proveedoras. Finalmente, en la última sección, agregamos nuestra recomendación sobre cual de los proveedores deberíamos escoger desde la perspectiva tecnológica (que era el departamento al que nosotros representábamos).

El documento lo entregué al director general, al director de ventas de ese proyecto y al hijo del dueño de la empresa, posteriormente hicimos una junta en la que explicamos el contenido del documento y dimos detalles que no venían en el documento, pero que teníamos gracias a nuestras continuas entrevistas con los proveedores.

Finalmente la dirección general optó por una cuarta opción: no implementar el proyecto.

Desafortunadamente no tuvimos la oportunidad de ejecutar el plan que construimos en un par de meses, pero nos quedó la experiencia de haber elaborado un ejercicio que dejó precedente. En ese momento nuestra organización entendió que era posible implementar proyectos mas allá de la capacidad instalada en el departamento. Aprendimos que podemos salirnos del molde y aventurarnos a administrar proyectos con recursos externos.

Esta experiencia puede parecer básica para muchos de nuestros experimentados lectores, sin embargo en su momento fue una experiencia que nos dejo un aprendizaje de algo a lo que no estábamos acostumbrados. Normalmente abordábamos los proyectos con la gente que teníamos y el arranque de proyectos se postergaba hasta que tuviéramos disponibilidad; con este nuevo esquema nos atrevimos a subcontratar los servicios de desarrollo mientras nosotros administrábamos el proyecto y lográbamos las metas de negocio.

Mas adelante la compañía pudo vivir la experiencia de implementar proyectos completos con personal externo de acuerdo a las necesidades de las diferentes áreas de la compañía. En otras ocasiones se contrató personal externo a largo plazo y no sólo por proyectos.

La compañía experimentó con una serie de contratos cuya negociación normalmente quedaba a criterio del administrador del proyecto obligando a éste a ejercitar esa área tan importante de la administración y liderazgo de proyectos que a veces dejamos de lado.

Por Fernando Valdez

La importancia del inicio del proyecto

Publicado el Julio 14th, 2011 en Inicio, Alcance, Comunicaciones por admin

kickoff-meeting.jpgYo fungía como líder de proyectos de sistemas en una empresa mexicana con un portafolio de proyectos extenso. Los proyectos eran para automatizar diferentes aspectos de las áreas de finanzas, cobranza, recursos humanos, servicio a clientes, etc.

En una ocasión el director de ventas me llamó diciendo que estaba por enviarme un email con datos sobre un proyecto que necesitaba que empezáramos cuanto antes. Le dije que lo esperaría y tan pronto como colgamos el teléfono llegó el correo.

Un poco después tome los datos que este director me había enviado y lo capturé en la base de datos de proyectos y en mi revisión semanal con el gerente de desarrollo le mencioné que habíamos recibido una nueva requisición y que necesitábamos priorizarla. Después de algunos comentarios al respecto mi jefe dijo que se comunicaría con el director para discutir prioridades y que después me comentaría como procederíamos con ese requerimiento.

Las especificaciones

El director había sido muy específico en sus requerimientos, mismos que definió a través de su gerente de ventas de la zona norte, así que el documento (por email) tenía especificados muchos detalles hasta con dibujos de pantalla (mock-ups o screen-shots). Al final del correo tenía una estimación de lo que ellos pensaban que debería tomar el desarrollo de ese proyecto. La estimación tenía mucho sentido, dado que el trasfondo de aquellos individuos, el director y el gerente, era de gente de Tecnología de Información.

El pre-análisis

Nosotros no empezamos a desarrollar el proyecto de inmediato, sino que fuimos terminando algunos otros pendientes y de vez en cuando nos reuníamos con ellos para ir esbozando los requerimientos y conociendo las necesidades para decidir acerca de la tecnología a usar.

Cuando los miembros del equipo se liberaron por completo, entonces nos dedicamos un poco más a juntarnos con los gerentes y supervisores para entender y levantar formalmente los requerimientos y después de una semana de hacer esto, el director preguntó si ya íbamos a acabar. El esperaba ver más de la mitad de los entregables implementados a esas alturas.

Cuando le dijimos que apenas estábamos terminando de documentar el análisis el director se incomodó y escaló el problema con mi jefe y con el jefe de mi jefe. Ellos le preguntaron que si había un email o documento en el que yo me comprometía para llevar ese avance en esa fecha, pero el mostró el primer email que me había enviado y mi respuesta allí decía que íbamos a empezar el proyecto tan pronto como revisáramos las prioridades del departamento y asignáramos los recursos. Adicionalmente le daba el número de folio de su requisición que ya había sido dada de alta en el sistema para control de proyectos. De tal manera que no tenía ningún compromiso documentado de mi parte, sólo tenía un par de correos y evidencia de algunas reuniones con otro personal, sin embargo, para el, eso era suficiente como para considerar el proyecto iniciado.

¿Por qué es importante un arranque formal del proyecto?

Un director ha llegado hasta allí por saber tomar decisiones con poca información o por haber desarrollado esa capacidad, el problema es que ellos esperan lo mismo de los que interactúan con ellos. Cuando un director da una orden, normalmente espera que se ejecute de inmediato y espera revisar métricas del desempeño de inmediato.

Hay directores expertos en Project Management, pero no estoy hablando de ellos ahora, ellos seguramente entenderán lo que se requiere para iniciar, planear, ejecutar, controlar y cerrar un proyecto. Yo hablo de aquellos que no tienen dicha preparación, para ellos es necesario un “trato especial”.

Comunicación

Es necesario comunicar cada estado en el que se encuentra el proyecto. Que el director tenga o no tenga experiencia en proyecto o que su estilo sea pedir y esperar de inmediato que todos se pongan a trabajar no es un defecto, es sólo una forma de trabajar. Es responsabilidad del líder de proyectos el comunicar en que etapa del análisis, diseño, desarrollo o control se encuentra el proyecto. Incluso si el proyecto se encuentra en una fase tan temprana como lo es su inicio, es necesario que lo comuniquemos.

El verdadero inicio del proyecto

El PMI® menciona en el PMBOK® que el inicio del proyecto nunca se tiene puntualmente definido en una sola fecha. Esto se refiere a que un proyecto puede nacer en un elevador mientras dos personas platican, por ejemplo, que “sería bueno que implementáramos un control de ventas más eficiente”. Más adelante, tomando este mismo ejemplo, estas dos personas podrían reunirse para comentar un poco más sobre ese asunto. Posteriormente podrían existir algunos correos yendo y viniendo acerca del mismo tema. Y de esta forma podría haber muchas otras comunicaciones que dieran lugar, por ejemplo, a un sistema de información que derivara de aquella iniciativa y que ese sistema de información fuera administrado como un proyecto. De tal forma que tiene sentido lo que el PMI® menciona cuando dice que un proyecto en ocasiones no tiene muy clara su fecha de inicio.

Para el equipo del proyecto, este debería “nacer” en el momento en el que se los involucra en el mismo. Cuando hay una estructura o cadena de mando aquella persona que es contactada para hacerse cargo del proyecto es la responsable de comunicar su progreso o delegar esta función a quien se hará cargo del mismo. Si bien el proceso de aprobación del proyecto o de revisión del portafolio y priorización de proyectos pudiera tomar algo de tiempo, es responsabilidad de la oficina de proyectos o del Líder del Proyecto el comunicar el estatus actual.

El problema

En muchas organizaciones no se tiene una Oficina de Proyectos que administre el portafolio, pero en cambio se tiene una gerencia que administra las operaciones y asigna responsables a los diferentes proyectos de acuerdo a diversos criterios como lo son línea de negocios, cargas de trabajo, etc. De tal forma que en algunas organizaciones nos encontramos con varios líderes de proyectos dependiendo de un gerente quien les asigna el trabajo y estos, hasta cierto punto, administran su propio portafolio que comúnmente consta de 10, 20 ó 30 proyectos que están esperando por prioridad y recursos para ser desarrollados.
La vida del líder de proyectos es agitada: preparar reuniones, asignar recursos, conseguir esos recursos, lidiar con ausencias de personal, ajustar el cronograma, monitorear el registro de riesgos, dar seguimiento a la lista de problemas (issue register), etc. Son algunas de las actividades que pueden mantener el día de un líder de proyectos totalmente ocupado.

Sin embargo, si se encuentra en la necesidad de administrar un subconjunto del portafolio de proyectos de la compañía o del departamento, es necesario que agende periódicamente un tiempo para la revisión de ese portafolio de proyectos que tiene asignado y que comunique el estado actual de los proyectos a los patrocinadores correspondientes.

Saca la cabeza del lodo

Un buen amigo mío y mi jefe en aquel entonces solía decirme “necesitas sacar la cabeza del lodo y respirar”. Efectivamente, para vivir necesitamos respirar. La respiración, que traducido a nuestra profesión representa los tiempos de evaluación, introspección, descanso, planeación  y liderazgo, proporciona a la vida de un líder de proyecto la perspectiva necesaria para resolver los problemas creativamente y también proporciona el tiempo necesario para comunicar los avances de los proyectos, aún cuando éstos no hayan iniciado todavía.

El fin de la historia

El proyecto de aquel departamento de ventas fue iniciado más adelante, después de haber aclarado y comunicado una serie de expectativas a sus patrocinadores.
Dimos un inicio formal al proyecto con la conducción de una reunión de kick-off a la que invitamos a los patrocinadores y a nuestro gerente, así como a los usuarios y nuestro equipo de proyecto. Las actividades que ya habíamos hecho las llamamos pre-análisis y esta etapa la definimos como necesaria para familiarizarnos con la idea que íbamos a transformar en un producto.

Ese fue el inicio real del proyecto desde nuestra perspectiva. Aún cuando el director de ventas pensaba que ya íbamos tarde, nosotros nos esmeramos en comunicar los progresos del proyecto y al final y después de algunas actualizaciones naturales del cronograma el proyecto terminó dando a luz un producto utilizable para ese departamento.

Conclusión

El inicio del proyecto muchas veces es impreciso, pero consideraremos que el proyecto inicia desde el momento en que somos asignados a él.

El líder de proyecto es responsable de la comunicación de un proyecto aún cuando no haya sido iniciado formalmente.

Iniciar formalmente el proyecto es importante, reduce incertidumbre, establece expectativas y le comunica al cliente o usuario que a partir de ese momento empezarán los esfuerzos por parte del equipo (no antes).

Hay que reservar tiempo a la semana para actividades de liderazgo. Este tipo de actividades ocasionalmente son momentos de preparación, reflexión, convivencia con el equipo, comunicación y replanteamiento de lo que se está viviendo en el proyecto.

Por Fernando Valdez

Riesgos vs Problemas

Publicado el Mayo 31st, 2011 en Planeación, Riesgos, General por admin

risk-register.jpgHace ya muchos años fui asignado a un proyecto cuyo objetivo era desarrollar un sistema que integrara algunas pantallas de aplicaciones ya existentes dentro de un solo flujo de pasos, algo parecido a un workflow o wizard (aplicación que tiene diferentes etapas en las que el sistema recibe información y cuyo orden de captura es importante. También puede verse como una serie de pasos para completar una tarea), dado que los sistemas estaban desarrollados en plataformas diferentes pude anticipar que tendríamos algunos riesgos y problemas que resolver en su momento.

Ambiente del proyecto

Yo trabajaba en una compañía de telecomunicaciones que recientemente había comprado una compañía de TV por cable y tanto nuestros sistemas como los de la nueva compañía habían sido creados para plataformas tecnológicas diferentes .

Iniciamos el proyecto con dos desarrolladores y un analista  quien también participaba de las decisiones técnicas del proyecto. Por parte de la empresa cablera habían asignado a su mejor ingeniero, al de mayor experiencia y antigüedad y a dos de los mejores técnicos de sistemas quienes habían desarrollado su plataforma de aprovisionamiento de información.

Riesgos del proyecto

Por ser un proyecto pequeño decidí no formalizar mucho el ejercicio de identificación de riesgos, además, mi clara inclinación por pensar que el riesgo preponderante eran las múltiples plataformas tecnológicas que debíamos integrar nubló mi ejercicio de análisis y búsqueda de otro tipo de riesgos.

A esas alturas mi risk register contenía sólo un registro y el plan de mitigación no tenía pasos concretos a seguir para evitar, transferir o mitigar el riesgo.

Uno de los sistemas, el más importante, no pertenecía a la compañía en la que yo trabajaba, sino a la filial recién adquirida, así que los riesgos aumentaban en ese punto. Los miembros de la compañía de TV no estaban del todo contentos con la transacción de compra-venta y era claro que también estaban nerviosos (las bolsas de trabajo están llenas de curriculums vitae de empleados  descontentos y nerviosos por el futuro de su compañía).

Adicional a todo esto, las fechas que había establecido la dirección comercial eran muy agresivas, ya que el sistema sería utilizado para aprovisionar información de ventas en las diferentes plataformas para lograr tanto el registro de la información del cliente como la configuración del servicio recién vendido.

El problema

Para hacer más corto el relato, a la altura en la que estábamos haciendo las primeras pruebas de integración de las plataformas, el empleado más importante de la compañía de TV fue sacado del proyecto para atender asuntos pendientes urgentes de su compañía y los empleados de apoyo renunciaron.

La compañía cablera asignó dos ingenieros más al proyecto, pero éstos no conocían las plataformas con las que estábamos trabajando, de tal manera que se anticipaba una larga curva de aprendizaje.

El intento por resolver el problema

En ese momento mi issue log se llenó inmediatamente. La lista de problemas que se había registrado era interminable. Era imposible atender tantos problemas de alta prioridad al mismo tiempo con poco apoyo por parte del equipo técnico y con la presión del equipo ejecutivo quien ya estaba lanzando las primeras campañas publicitarias en las que le ponían fecha al lanzamiento del nuevo servicio “Triple Play” (Telefonía, Internet y TV por cable).

Fueron largas noches de trabajo las que invertimos para resolver todos los problemas que se generaron. La compañía de TV regresó al experimentado ingeniero al proyecto y eso favoreció mucho a la pronta resolución de los problemas.

Lecciones Aprendidas

Después de que la adrenalina bajó me puse a pensar, ¿por qué un proyecto que ciertamente presentaba reto se había convertido en un dolor de cabeza tan pronto? Debía haber una manera de prever los problemas que ocurrirían con cierta anticipación y no tan repentinamente.

Analizando encontré algunos defectos en mi manera de administrar el proyecto, principalmente el de no haber hecho un ejercicio adecuado de administración de riesgos.

La administración de riesgos supone la creación de un registro de riesgos, un análisis cualitativo y cuantitativo de los riesgos, una discriminación de aquellos poco probables de ocurrir o con poco impacto y la creación de planes de mitigación, transferencia o aceptación junto con un plan de contingencia para cuando ocurran.

Con lo anterior quiero decir que independientemente del tamaño y naturaleza del proyecto debemos hacer un análisis de los riesgos y registrar estos en un documento. No importa si el riesgo es pequeño o improbable, como líderes del proyecto necesitamos registrarlos.

Una vez establecido este documento al que llamamos risk register, es necesario analizar qué tan probable es que ocurran esos riesgos y, de hacerlo, cuál sería el impacto para el proyecto. Hay muchas técnicas para hacer esto, pero más bien quiero concentrarme en el siguiente paso que fue el que me provocó más problemas.

Hasta este punto un riesgo puede ser mitigado (reducido su probabilidad de ocurrir), evitado o aceptado, es decir, es posible planear maneras para que su impacto sea menor, su probabilidad sea menor o simplemente planear cómo vamos a afrontar los problemas que surgirán en el momento en el que ocurra.

Cuando un riesgo ocurre esto da lugar a problemas (issues) y es aquí donde tenemos que dejar de administrarlos dentro del registro de riesgos y empezar a manejarlos dentro del log de problemas para  resolverlos de acuerdo a los planes definidos de mitigación y respuesta .

El riesgo de perder a los ingenieros de la compañía de TV por cable se hizo realidad y yo ni si quiera lo había considerado en el risk register. Los problemas afloraron y yo no tenía planes de contingencia. Esto dio a lugar esfuerzos desmesurados, largas noches y descontento en el equipo.

Recomendaciones finales

Antes de terminar este post quiero hacer énfasis en un par de cosas. Aunque considero que dejé claro que hay que analizar todos los riesgos probables dentro de nuestro proyecto, esto no quiere decir que debemos planear como si todos fueran a ocurrir.

Debemos ser prácticos y planear sobre aquellos que son más probables de ocurrir y sobre aquellos cuyo impacto sería mayor en el momento de ocurrir. Por ejemplo, yo no me enfocaría en realizar planes de contingencia para un riesgo que tenga 0.05% de probabilidad de ocurrir y/o cuyo impacto nos obligue solamente a reemplazar un foco con valor de 0.50 pesos, pero definitivamente si registraría el riesgo a manera de documentación.

Otra cosa, los riesgos se administran como eventos probables de ocurrir y mientras haya tiempo para planear en acciones que los eviten o disminuyan, hay que hacerlo, es una inversión. Los problemas se administran como eventos que ya ocurrieron y se espera que se resuelvan de acuerdo con el plan de contingencias.

En resumen, en el mundo ideal no debería haber sorpresas en los proyectos. Los líderes de proyectos son contratados para llevar un proyecto a un término exitoso y con el menor número de sorpresas.

Por Fernando Valdez

Problemas en el proyecto

Publicado el Mayo 4th, 2011 en Documentación, Riesgos, Comunicaciones por admin

problemas.jpgHace tiempo iniciamos un proyecto con muchos entregables, poco tiempo para completarlo, poca definición y de incalculable valor para el cliente… ¿te suena familiar?

Ésta es la vida real.

Los problemas son lo que hacen que el cliente nos llame. Los problemas son los que hacen girar la rueda del intercambio comercial entre clientes y empresas de productos y servicios. Sin los problemas no tendríamos trabajo.

Muchos de los lectores seguramente son personas versadas en las técnicas de administración de proyectos, unos a nivel introductorio y otros avanzado, pero ambos, a su propio nivel, se encuentran diariamente con una serie de problemas que los hace aplicar las diversas técnicas aprendidas ya sea experimentalmente o formalmente para conseguir una solución favorable.

Mi proyecto no fue la excepción. Desde su propio origen nos encontramos con el problema de balancear las variables tiempo, alcance y calidad.

Pensando en esto, en las técnicas y herramientas que hay para resolver problemas de administración de proyectos, me puedo dar cuenta que hay mucho escrito sobre administración de proyectos. Constantemente recibo correos que me invitan a visitar un sitio, a comprar un template, a adquirir una metodología de administración de proyectos, a inscribirme en un curso que me enseñará “lo que nadie en el mercado está enseñando sobre administración de proyectos”, a asistir a la reunión mensual en la que tratarán “temas de relevancia para los administradores de proyectos en estos agitados tiempos”,… la lista continúa interminablemente.

He revisado decenas de metodologías, asistido a más de cien seminarios web, leído miles de páginas, visitado centenares de sitios web sobre administración de proyectos y descargado innumerables formatos y templates para su uso en mis proyectos. Además hice un diplomado en administración de proyectos que resultó en mi certificación como PMP, sin embargo ninguno de estos esfuerzos, algunos gratuitos y otros muy bien cobrados, me dieron las habilidades para resolver los problemas de mis proyectos.

Y es que no solamente se trata de conocimientos y metodologías, se trata de muchas cosas más. Desde luego que los conocimientos adquiridos trabajan a nuestro favor cuando nos enfrentamos a un miembro del equipo ocioso, o cuando balanceamos cargas de trabajo, o cuando necesitamos apresurar la entrega de un paquete de trabajo, o cuando el cliente pide un cambio. Hay suficientes páginas escritas sobre cómo lidiar con estos y otros problemas, pero siempre el nuestro parece algo diferente a lo que dice en el libro de texto.

He observado que hay tres actividades que podemos llevar a cabo para incrementar nuestras habilidades en la resolución de problemas y son las siguientes:

1. Enfrentar el problema. No se trata de darle la vuelta, evitarlo o buscar alternativas, se trata de reconocer que existe y emprender el camino hacia su resolución. Necesitas exponerte a los problemas. Quizás necesites tus habilidades más recientemente adquiridas en el mega-seminario de administración de proyecto o simplemente usar tu sentido común, pero lo importante aquí es concentrar tu atención en la búsqueda de la mejor solución al problema y no en evadirlo.

2. Documentar los resultados de tus esfuerzos por resolver el problema. Esto es algo así como las lecciones aprendidas parciales de tu proyecto. Es tu experiencia. Esto es el legado que vas a dejar al mundo de la administración de proyectos. Es el manual de resolución de problemas que le estás heredando a aquellos que están al inicio, en medio o al final de la carretera que representa la administración exitosa de un proyecto de cualquier naturaleza. Este registro es invaluable. Es lo que todas las compañías deberían estar ofreciendo dentro de sus capacitaciones. No ha habido seminarios más interesantes a los que yo haya asistido que a aquellos en los que se relatan lecciones aprendidas de un proyecto en específico. Es experiencia en acción, es valor agregado en toda su expresión.

3. Buscar problemas por resolver. Ya encontramos problemas en nuestro proyecto, ya los resolvimos, ya registramos las lecciones aprendidas y el problema quedó resuelto. La única manera para practicar la resolución de problemas es exponiéndonos a ellos de manera regular. Si no tienes problemas en tu proyecto seguramente es porque no has observado bien. Si no ves problemas seguramente es porque no has buscado en el lugar correcto. Los problemas están allí, tienen un reloj haciendo tic-tac, a punto de explotar cuando menos nos lo esperamos. Si no buscamos los problemas ellos nos encontrarán a nosotros pero quizás nos encuentren con la guardia baja.

Un proyecto se trata de resolver problemas. El trabajo se trata de resolver problemas. La vida se trata de resolver problemas. Aprende a vivir con ellos, a buscarlos, a identificarlos, a reconocerlos hasta que se vuelva tu segunda naturaleza, aprende a enfrentarlos, aprende a olfatearlos a lo lejos, aprende a prevenirlos antes de que ocurran… esto te dará un altísimo nivel de empleabilidad.

Los mejores administradores de proyectos con los que he tenido el privilegio de trabajar no estaban certificados en Project Management, los mejores no tenían cientos de horas de capacitación en administración de proyectos. Los mejores que yo he conocido sabían identificar problemas, resolverlos, anticiparlos y los enfrentaban agresivamente, inteligentemente y, como una osa que sentía la amenaza de un extraño, embestían el problema hasta dejarlo fuera de combate para siempre.

¿Qué hay de ti y de mí, que nos reunimos virtualmente para compartir esta lección, que buscamos seminarios y lecturas interesantes para afilar nuestras armas para la batalla en el campo de la administración de proyectos?, ¿no deberíamos tener un mejor desempeño?

Así es mi amigo lector, sal, busca y enfrenta tus problemas, pelea la buena batalla, la batalla que está ganada, la batalla de la profesionalización y aplicación de mejores prácticas en el campo de tu experiencia y cuando tengas la victoria documenta, comparte y aprende… y prepárate para el siguiente round.

Te deseo éxito.

Por Fernando Valdez

Un proyecto en aprietos

Publicado el Marzo 15th, 2011 en Inicio, Planeación, Alcance, General por admin

aprietos.jpgHace poco vino un colega para pedirme consejo con respecto a un proyecto al que acababa de ser asignado. Al parecer el proyecto no era nuevo, era un proyecto que ya había fracasado y ésta era la “segunda vuelta” que iban a dar, pero con algunos cambios, entre ellos, el contratar a un Administrador de Proyectos profesional a quien pedirían cuentas sobre los resultados del proyecto.

En cuanto llegó le pedí que me explicara cómo les había ido en el primer intento y, de acuerdo a lo que le habían comentado, el me relató lo siguiente:

Entorno del proyecto
Se trata de una escuela que quiere ampliar sus servicios educativos para que los alumnos de preparatoria tengan otros medios de ponerse al corriente con clases que no tomaron o que quisieran repasar. El director y el consejo escolar planearon tener un sistema computacional que les permitiera tomar las clases sin necesidad de un instructor.

Debo mencionar que me interesó mucho el caso porque tocaba tres de mis puntos fuertes: Sistemas Computacionales, Project Management y la industria del aprendizaje asistido por computadora (e-Learning).

De manera que le pedí que me comentara cuales habían sido las acciones que el equipo de proyecto había emprendido antes de llamarlo a él para apoyarles, y el continuó diciendo:

Creación del equipo de proyecto
El director de la escuela armó un equipo para abordar el proyecto. Viendo la necesidad de crear material didáctico eligió a cuatro profesores y un líder de proyecto.

Definición de alcance del proyecto, roles y tiempos
El equipo se concentró originalmente en definir el alcance del proyecto y aclarar todas las dudas que tuvieran con respecto a lo que se haría. Después invitaron al director para que estableciera las prioridades de las actividades, así como para solicitar su apoyo y para motivar a los participantes de este esfuerzo ya que todos los miembros del equipo continuarían con sus actividades normales y, además, estarían desarrollando los entregables del proyecto.

Los integrantes del equipo definieron horarios en los que trabajarían en este esfuerzo y definieron el número de cursos a desarrollar, que se estableció en 18 cursos.

En las primeras reuniones también se detectó que ninguno de los participantes tenía experiencia previa en el modelo de aprendizaje automatizado, si bien eran expertos en la enseñanza y preparación de material, nunca habían participado en un proyecto en el que tuvieran que implementar el marco tecnológico necesario, por lo que decidieron contratar a una empresa que les apoyara con esta parte de los entregables.

Finalmente, el equipo de proyecto definió la fecha de entrega de los cursos para tener un marco de referencia del fin del proyecto.

Inicio del proyecto
El proyecto arrancó con la asignación de algunos maestros adicionales para que apoyaran con la elaboración de los cursos. Los consultores definieron los formatos en los cuales los maestros pondrían la información de acuerdo a su experiencia docente. Adicionalmente los consultores capacitaron a los profesores en el uso de la plataforma tecnológica a emplear para el proyecto.

Desarrollo del proyecto
Los profesores empezaron a desarrollar los cursos por separado y cuando terminaban se los enviaban al equipo del proyecto para que estos los revisaran y aprobaran. Los consultores continuaron apoyando con respuestas a las dudas sobre el uso de la plataforma y cargando archivos en esta.

Durante el tiempo designado los maestros elaboraron los materiales de los cursos hasta terminar. Cuando enviaron los materiales para revisión, el equipo de proyecto notó que aunque todos usaron la misma herramienta para elaborarlos, los cursos no eran uniformes, algunos eran apropiados y apegados a los objetivos del aprendizaje y otros no lo estaban en lo absoluto. Algunos tenían una buena presentación mientras otros no la tenían.

Cambio de rumbo
El líder del proyecto solicitó la presencia del director de la escuela para conocer su opinión y éste determinó que el material creado no cumplía con los objetivos del aprendizaje del alumno y solicitó que le agregaran características de animación y mejores transiciones entre las diapositivas para facilitar el aprendizaje.

Tomando lo anterior como un nuevo rumbo para el proyecto se calcularon las implicaciones y se determinó que la entrega del proyecto se retrasaría, el costo de la consultoría se elevaría y se requeriría que los maestros trabajaran horas extra en el material que ya habían realizado (re-trabajo).

En búsqueda del culpable
Cuando se evaluaron estas implicaciones y se revisaron los cambios presupuestales se intentó encontrar dónde había estado el problema. Los maestros le echaron la culpa a los consultores porque éstos no les estaban dando toda la información acerca de la plataforma que estaban operando. Los consultores le echaron la culpa a que había habido un cambio en el alcance del proyecto. El equipo original del proyecto argumentó que el problema era que no se había ofrecido una compensación monetaria para los maestros por haber trabajado específicamente en ese proyecto. Alguien más argumentó que el problema estaba en el proceso y que era necesario establecer más y mejores puntos de revisión en el mismo.

En ese momento el director autorizó la contratación de un Project Manager externo para hacerse cargo… así es, ese era mi amigo.

¿Te suena familiar este caso?
Desafortunadamente hoy en día todos, y no me da miedo generalizar, todos nos enfrentamos a proyectos de algún tipo, con poca o nada de preparación para enfrentarlos (administrarlos).

Mi amigo es un PM novato y afortunadamente el proyecto que dejaron en sus manos es un proyecto pequeño.  ¿Qué le habrías aconsejado?, ¿por dónde empezar?

Con respeto a tus propias opiniones me permito comentarte lo que yo le sugerí.

Mis preguntas
Antes de recomendar nada, le hice a mi amigo un par de preguntas. La primera de ellas fue: ¿Tienes un Project Charter? La constitución del proyecto o Project Charter es un documento en el que se esboza información importante del proyecto en términos del alcance, tiempos, involucrados, pero sobre todo, se establece claramente  la autoridad que adquiere el Project Manager sobre el equipo del proyecto y lo responsabiliza de tomar las decisiones que favorezcan a que el proyecto se termine dentro de las definiciones de alcance, tiempo, costo y calidad. Este documento, que debe estar firmado por el director de la escuela también sirve para definir el rol del director y otros interesados.

Mi segunda pregunta fue: ¿Tienes un WBS? La estructura de descomposición del trabajo o Work Breakdown Structure (WBS) es un documento que ayuda a descomponer el objetivo final del proyecto en partes más pequeñas y manejables y que puede ser usado no sólo para la planeación del proyecto, sino para el seguimiento, la presentación de avances y la definición de los responsables de cada paquete de trabajo. Con un WBS puedes saber cuánto costará el desarrollo de cada entregable y cuanto se retrasara el proyecto si una tarea se retrasa.

Desde luego que hay muchas otras herramientas que ayudan en la organización de un proyecto, pero para este caso y en general para proyectos pequeños elaborados en organizaciones informales o donde se tiene poco conocimiento del control de proyectos, estas dos herramientas son vitales. Los beneficios que traen, entre otros, son los siguientes:

  • Establece jerarquía dentro del equipo de proyecto
  • Comunica los acuerdos con respecto al alcance del proyecto
  • Define responsables por cada parte del proyecto
  • Identifica la parte emproblemada del proyecto

Adicional a estas dos herramientas yo agregaría un nivel mayor de detalle en las expectativas de calidad de cada curso. Hay tantas formas de hacer las cosas como participante en las actividades del proyecto, así que se requiere un estándar como punto de partida. La verificación de la calidad en los sistemas es muy sencillo, sólo es necesario establecer a un nivel aceptable de detalle cuales son las expectativas del usuario o cliente y verificar que el producto final cumpla con ellas.

Si se cuenta con las herramientas adecuadas de trabajo, seguramente se contará con un sistema que ayude en la elaboración de WBS y que permita agregar especificaciones por cada entregable, de tal manera que no se requeriría otra herramienta, sino solamente una disciplina por agregar la información allí y mantenerla vigente a lo largo del proyecto.

Aún más, debe establecerse un proceso de integración de cambios, esto es, un procedimiento por el cual se detalle cómo vamos a proceder cuando haya un cambio solicitado para alguno o varios de los entregables del proyecto. Comúnmente este proceso luce así:

  1. Un usuario solicita un cambio
  2. El cambio se recibe en un formato específico
  3. El cambio se evalúa y se pronostican los cambios en el enunciado de alcance, duración del proyecto y costo
  4. Se procede a la autorización del cambio.
  5. Si el cambio es autorizado por el equipo ejecutivo del proyecto, se integran los cambios en el WBS, Enunciado de Alcance, Cronograma, Documento de Riesgos, etc.
  6. Si se rechaza, se notifica a los interesados.

Mi amigo estaba muy bien familiarizado tanto con las herramientas como con los procesos a implementar, así que no fue difícil que supiera cuál era el siguiente paso a dar. Sin embargo me hizo una observación: “Cuando dominas las herramientas y técnicas de administración de proyectos es fácil caer en la tentación de establecer todo un complicado proceso de administración de proyectos cuando lo que necesitas es abrir los canales de comunicación, definir los roles y las responsabilidades de la gente y documentar los acuerdos de manera formal”.

¿Cuántas veces hemos sobredimensionado un proyecto sólo para hacer uso del software de administración de proyectos en el que nos acabamos de certificar?, ¿o sólo para implementar la metodología que utiliza aquella súper compañía que ha sido exitosísima a nivel mundial?

La administración de proyectos parte de la necesidad de hacer que el proyecto sea exitoso y es un medio para lograrlo, no el fin último de un proyecto. Si en el futuro te encuentras con un reto de este tipo o más complicado, te invito a contestar las siguientes preguntas: ¿Cuál es el objetivo final del proyecto?, ¿Qué puedo hacer para ayudar a conseguir el objetivo del proyecto?, ¿Cómo puedo usar mis habilidades y técnicas en administración de proyectos para conseguir el resultado esperado?

¿Qué recomendaciones le darías a mi amigo para la etapa de ejecución, control y cierre de su proyecto?

Por Fernando Valdez

El staff adecuado del proyecto

Publicado el Enero 6th, 2011 en Inicio, Planeación, Recursos Humanos, Comunicaciones por admin

En una ocasión tuve la oportunidad de dirigir un grupo de ingenieros de pruebas para un proyecto de software en el que participaríamos revisando que la traducción del inglés al español de una aplicación se hubiera elaborado adecuadamente. Tendríamos que revisar decenas de pantallas y cientos de textos y, cada vez que encontráramos un error, deberíamos reportarlo en una herramienta diseñada para el reporte de errores.

La experiencia en ese proyecto fue interesante y dedicaré otro post para describirla, pero en esta ocasión quiero comentar sobre la experiencia que tuve trabajando  con ese particular equipo de proyecto. Mi equipo local en México constaba de 5 ingenieros de verificación, pero el equipo en Nueva Jersey, Estados Unidos, estaba compuesto por Desarrolladores de Software, un Project Manager, varios Ingenieros de Testing funcional y dos Stakeholders que compartían la misma característica: todas eran mujeres. A través de las diferentes etapas del proyecto tuve oportunidad de acordar, discutir, negociar, prometer, cumplir y todas las interacciones normales que se tienen en un proyecto con las miembros del equipo y siempre llegamos a acuerdos concretos que finalmente dieron como resultado la terminación satisfactoria del proyecto. No miento si les digo que tuvimos fricciones, retrasos y expectativas temporalmente no cumplidas, pero al final el proyecto fue terminado de acuerdo al plan maestro de la Gerente del Proyecto.

Al final organicé una reunión con mi equipo local para reflexionar sobre nuestro desempeño durante el proyecto (lecciones aprendidas). La reunión fue muy dinámica y todos hacíamos comentarios sobre los cambios de alcance, lo ajustado de las fechas, los problemas de comunicación, etc., pero nunca nadie mencionó las ventajas o desventajas de trabajar con un equipo de personas de diferentes nacionalidades (Norteamericanos, Rusos e Indios y, desde luego, Mexicanos) y completamente del sexo opuesto al nuestro. Y es que, en realidad, eso no era relevante. Todos se habían mostrado enfocados en las metas del proyecto y simplemente fuimos “ciegos” a esos factores. Las compañeras siempre se condujeron profesionalmente y nosotros hicimos también lo propio. Simplemente no había nada de que decir al respecto, todos trabajamos enfocados y profesionales.

Traigo a colación este tema porque no hace muchos años tuve a mi cargo un equipo de proyecto en el que participaban solamente mujeres y yo era el líder del proyecto, todos éramos mexicanos. A los pocos días de haber empezado el proyecto los conflictos empezaron a surgir entre las miembros del equipo, había comentarios y situaciones tensas, el progreso de una de ellas era dificultado por otra hasta que tuve que intervenir y decirle a ambas en una reunión: “no sé qué problema tienen, pero el proyecto se está viendo afectado, necesito que resuelvan su problema porque a este paso no vamos a tener éxito”. Lo que me sugirieron ellas fue separarlas y eliminar toda interacción, pero la verdad es que el equipo era muy pequeño y eso no era factible. Por otro lado, cambiar uno de los recursos en esa etapa del proyecto era poco efectivo, así que tuve que involucrarme y apoyar en su resolución.

Cuando terminé ese proyecto y, dado que en aquella compañía yo tenía un equipo fijo de proyectos (a diferencia de otros lugares en los que se comparte un pool de recursos bajo el mando de un gerente funcional y que participan indistintamente en los diferentes proyectos) tomé la decisión de contratar exclusivamente hombres para mi equipo; según yo eliminaría la variable ‘conflicto’ de mis proyectos, pero la experiencia fue totalmente diferente.

Durante varios proyectos con mi nuevo equipo todo salió muy bien, sin embargo el avance fue lento y los conflictos acerca de la mejor técnica a usar para implementarlo fueron muchos. De tal manera que me puse a pensar detenidamente cuál sería la formula exitosa en la creación de mi equipo. No podía simplemente contratar personas del mismo género, así que consideré algunas otras variables.

A continuación describo variables que me ha sido de mucha utilidad considerar cuando armo un equipo de proyecto:

1. Problemas personales. Todos tenemos problemas, pero aquí me refiero a aquellas personas que tienen problemas que exceden el promedio normal (si es que el término’ normal’ pudiera ser cuantificado). En una ocasión trabajé con una persona con serios problemas de salud en su persona y en su familia. Constantemente solicitaba irse temprano, llegar tarde, salir “un momento”, “trabajar” en casa, etc. Normalmente llegaba a la oficina tarde y bajo el influjo de alguna droga para reducir el dolor o eliminar síntomas de la gripe. Había sido intervenido quirúrgicamente mas de 7 veces de las cuales 3 habían sido situaciones graves. Al menos una vez por mes su familia o él sufrían de algún encuentro cercano con la violencia de la ciudad (robo, amenazas, choques, etc.). A esto me refiero con problemas que exceden el promedio.

mentor-team-copy.jpgEn una ocasión iba manejando de regreso a mi casa y me detuve en un semáforo frente a una empresa que estaba solicitando personal. En el cartelón que colgaba de la puerta principal decía: “Se solicitan operarios. Mayores de 18 años, sexo masculino, SIN PROBLEMAS”. Me dio risa leer eso, pero no decía más que la verdad: un líder de proyectos desea que su proyecto fluya conforme al plan y por eso es necesario tener las habilidades para lidiar con imprevistos, pero cuando uno se enfrenta a una persona que es un imán para los problemas debemos empezar a evaluar si esos problemas son reales o no, pero de cualquier forma se tienen que tomar decisiones para que estos no afecten al proyecto. En una ocasión un miembro muy importante de mi equipo al que todos acudían en búsqueda de respuestas perdió su auto y me solicitó trabajar por los próximos meses en casa, a lo que yo le contesté: “Aquí en la compañía estamos para ayudarte, tienes todo nuestro apoyo pero el problema sigue siendo tuyo. Dime cómo podemos apoyarte para que tu resuelvas el problema, pero te necesito aquí con el resto del grupo”. Este compañero tenía un hermano trabajando en nuestra compañía y que vivía muy cerca de su casa, así que optó por venir a la oficina compartiendo gastos de gasolina y conviviendo más con su hermano.

2. El género. Voy a mencionar mis observaciones trabajando con hombres vs. mujeres

  • Las mujeres aportan mucha continuidad a los proyectos, los hombres normalmente están en busca de mejores oportunidades de trabajo y rotan con mayor frecuencia de una compañía a otra, las mujeres en cambio, cuando se encuentran en una atmósfera agradable de trabajo y su remuneración es justa tienden a “echar raíces”, lo cual es bueno para la estabilidad del equipo.
  • Los hombres tienen dentro de sus prioridades mas altas el trabajo y su desarrollo dentro de la compañía, por lo que estarán buscando hacer las cosas de la mejor manera posible, investigarán nuevos métodos, permanecerán largas horas en la oficina dando solución a los problemas del proyecto y sacrificando en ocasiones su vida personal y familiar, etc., mientras que las mujeres tienen su prioridad más alta en la familia, las relaciones y el equilibrio. Comúnmente las mujeres son más rápidas para dar soluciones porque no invierten mucho tiempo para encontrar la mejor solución, cuando encuentran una solución viable al problema la implementan avanzando mas rápido que muchos hombres.
  • Las mujeres involucran emociones en el proyecto, lo cual agrega una atmósfera interesante y divertida al proyecto, sin embargo esto puede causar conflictos.
  • Los hombres al cabo de un año o más solicitarán un aumento, más responsabilidad o ambas. Esto no es un problema, simplemente necesita ser administrado.
  • He observado que la relación laboral hombre-hombre y hombre-mujer son muy efectivas, pero en muchos de los casos habrá conflictos con relaciones de tipo mujer-mujer. Tiende a haber tensiones mayores a nivel personal.

En general, cuando necesito que un proyecto se realice rápidamente y bien hecho suelo incluir mujeres en el equipo. Por el contrario, si necesito estabilidad en el producto final o se trata de una nueva tecnología o de crear algo no hecho antes elijo hombres, pero mi mejor recomendación siempre será tener un equipo mixto (hombres y mujeres) de gente talentosa y que desea crecer con la empresa.

3. El temperamento. No pretendo hacer de esto un curso sobre los diferentes temperamentos, solamente mencionaré los que han sido definidos por aquellos dedicados a su estudio. Existen cuatro temperamentos básicos: Colérico, Flemático, Melancólico y Sanguíneo. No existe nadie con un temperamento puro, es decir, todos compartimos características de dos o tres temperamentos, pero definitivamente poseemos más características de uno de ellos que de los demás.

Mi recomendación es que investigues cuál es tu temperamento y cuál es el temperamento de los miembros de tu equipo. Muchos de los conflictos personales surgen porque no sabemos como es más efectiva la demás gente. Por ejemplo, si tengo a un colérico en mi equipo desde luego que evitaré dar demasiados detalles en la explicación, iré al grano y dejaré que el o ella investiguen el resto porque sé que es lo que les gusta hacer. Por el contrario, si asignaré una actividad a un flemático no esperaré a que el tome la iniciativa, pero si puedo esperar un trabajo individual excelentemente elaborado. A un sanguíneo lo enviaré a negociar los alcances y a presentar los avances y a un melancólico lo concentraría en la elaboración de índices de productividad o en la inspección de la calidad del trabajo realizado.

Mi mayor recomendación a este respecto es que no busques gente igual a ti o con tus mismas habilidades, mismo carácter o mismos métodos de resolver los problemas, la diversidad hace al equipo dinámico y exitoso.

Esta lista de variables definitivamente no es exhaustiva y contiene elementos meramente basados en mi experiencia y mi opinión, ustedes podrán diferir y abundar en las consideraciones para formar el equipo perfecto aunque creo que dicho concepto no tiene un correspondiente en la realidad.

Conclusiones

Quisiera concluir mencionando algunas acciones que considero necesario implementar para tener un equipo exitoso.

  • Necesitamos buscar que nuestros integrantes del equipo tengan los conocimientos técnicos que estarán utilizando diariamente (hard skills), y capacitarlos para incrementarlos y perfeccionarlos.
  • Debemos desarrollar a nuestros integrantes en el área de habilidades relacionales o soft skills, particularmente en el área de comunicación. Conocí a un contador que era altamente efectivo en la técnica contable, pero que no le gustaba comunicar las malas noticias. Es necesario comunicar las buenas y las malas noticias, después de todo es mejor saber que se tiene cáncer y combatirlo que morir a los pocos meses.
  • Entre los integrantes del equipo debe haber transparencia, respeto y un ánimo por conseguir la calidad en los entregables desarrollados. Cuando se tiene apertura de lo que está sucediendo en el proyecto y en nuestras vidas particulares es mucho más fácil entender los problemas y desarrollar planes alternativos para conseguir el éxito.
  • Debemos ser promotores de la retroalimentación al interior de nuestros equipos. La retroalimentación se hace pronto, sin rodeos y orientada a resolver los problemas, no a molestar a las personas. Una retroalimentación positiva no se hace con respecto a las características físicas o económicas de una persona, sino hacia sus habilidades y su actitud.

Les deseo muy feliz año nuevo y éxito en sus proyectos.

Por Fernando Valdez 

 
© LiderDeProyecto.com - Todos los derechos reservados. "PMI" y el logo de PMI son marcas registras en los EUA y en otros países; "PMP" y el logo PMP son marcas registradas de certificación; PMBOK® es una marca registrada en los EUA y en otros países. CMMI® es una marca registrada en los EUA y en otros países por el Carnegie Mellon® Software Engineering Institute. UML® y OMG® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada en los EUA y en otros países por IBM Corp.