Andares de un proyecto

Aceptando el reto

Recientemente iniciamos un proyecto para un cliente estadounidense. Nuestro cliente quería un sitio web en el que se incluyera un componente de donaciones para una asociación civil sin fines de lucro, por lo que el presupuesto era muy ajustado. Adicional a esto, el cliente necesitaba que el sitio estuviera operando para inicios del año, lo que nos dejaba un calendario muy ajustado para terminar. La fecha de entrega no era negociable porque ya se había publicado la fecha del inicio del concurso que recaudaría los fondos y cada día que fuera entregado tarde el sitio representaba una pérdida en el potencial de recaudación.

shutterstock_7861366.jpg

Previo al proyecto

El cliente en EUA de primera instancia buscó compañías en ese país para que le hicieran el trabajo, pero con el presupuesto reducido y, sobre todo con el calendario tan apretado, tres compañías le rechazaron el proyecto. Posteriormente encontró un par de compañías basadas en India que accedieron a hacer el sitio por el presupuesto ofrecido, pero ninguna de las dos compañías ofrecieron terminarlo a tiempo, de hecho, ambas coincidieron en que lo podrían hacer en el doble del tiempo presupuestado.

Finalmente buscaron en México y siendo nosotros socios comerciales en proyectos pasados nos solicitaron la implementación. Revisamos la factibilidad y decidimos abordar el proyecto pero con una metodología ágil en la cual redujéramos algunos costos. La propuesta fue aceptada e iniciamos el proyecto.

Factores de riesgo

Adicional a la metodología ágil, otra estrategia que implementamos para reducir el costo fue conseguir personal externo a nuestra compañía que hiciera el trabajo con un precio por debajo de nuestro propio costo y buscamos personal en entidades socioeconómicas de menor nivel (fuera de la ciudad de Monterrey) y con los conocimientos técnicos para hacer la tarea.

Entrevistamos a algunos individuos y finalmente contratamos a dos de ellos en una ciudad a más de 2,000 kilómetros de distancia.

shutterstock_98130041.jpg

El proyecto involucraba el desarrollo sobre un Sistema Administrador de Contenido (Content Management System o CMS ó por sus siglas en inglés) que nuestro equipo nunca había utilizado y también involucraba la interacción con una entidad para la recepción de donaciones de manera segura, cosa que tampoco habíamos implementado antes.

Todo esto preparaba una atmósfera de riesgo adicional en el proyecto sin embargo decidimos tomar el reto con el afán de dar el servicio y con la expectativa de hacer algo que otros no habían querido hacer.

Las fiestas decembrinas, el fin de año, el equipo de trabajo a distancia, la metodología ágil, el presupuesto cerrado del proyecto, la fecha agresiva de entrega del proyecto y la tecnología que nuestro equipo no dominaba eran riesgos evaluados pero no poco considerables.

La ejecución del proyecto

En las primeras fases todo parecía ir bien hasta que solicité ver físicamente los entregables, empezamos a notar que no estaba todo lo que los externos decían que iban a completar. El líder de los externos empezó a postergar entregables de un sprint a otros posteriores y lo que fuimos recibiendo eran entregables incompletos.

Hicimos la primer presentación del avance al cliente de manera exitosa indicando que postergaríamos algunos de los entregables para una presentación posterior y el cliente aceptó.

Llegaron las festividades decembrinas y por un tiempo no recibimos avances considerables. El equipo externo estaba localizable, pero los entregables no se completaban. Establecimos una estructura de revisiones más cercanas que el equipo externo no pudo cumplir ya que no tenían siquiera una estructura de trabajo formal.

shutterstock_20302609.jpg

En subsecuentes revisiones con el cliente, éste se mostró preocupado por el escaso avance y empezó a cuestionar nuestra capacidad de entrega del producto a tiempo, por lo que me vi forzado a tomar por completo el control del equipo externo aún cuando su líder se resistía a ser administrado.

Iniciamos juntas diarias con el equipo remoto y establecimos metas claras diariamente para ir concluyendo cada uno de los entregables. También concentré al equipo en pocas actividades de alto valor, esto nos permitió ir acabando lo más importante aún que fueran pocos entregables y evitar tener muchos medios avances.

Agregué un equipo de pruebas que no era de ingenieros de pruebas (QA Testers), sino un equipo de desarrolladores de sistemas que empezaron a probar cada uno de los entregables que a su vez el equipo de externos iba produciendo. Esta decisión tenía tres objetivos: 1) reducir el tiempo del ciclo entrega-testing-documentación-remediación-entrega, 2) involucrar a nuestro personal técnico en la solución desarrollada, para que pudiera hacerse cargo de algunas partes del desarrollo del sitio en un momento dado, y 3) para que nuestro equipo apoyara en la remediación de algunos defectos, de tal forma que redujéramos la cantidad de trabajo enviada a los externos para remediación.

Continuamos con las revisiones diarias que a la vuelta de las semanas se volvieron muy cansadas ya que no permitíamos que el equipo se fuera a descansar sin concluir las metas propuestas por ellos mismos en el día. Debido a algunos problemas de actitud que el equipo de externos tenía, las revisiones se volvieron tortuosas, sin embargo para mediados del mes de enero, muy cerca ya de la fecha de entrega, declaramos como terminado todo el sitio y solo quedaron algunas actividades de pruebas y remediación de errores.

Las pruebas finales

shutterstock_56950768.jpgHacia el fin del proyecto invitamos al cliente a entrar al sitio para que validara toda la funcionalidad, el accedió e invitó a tres integrantes de su empresa para probar el sistema. Nosotros les compartimos el acceso a una herramienta para el reporte y seguimiento de los errores encontrados y en ese sistema ellos fueron capturando cada problema encontrado. Nuestro equipo revisaba la lista de problemas encontrados y priorizaba  su atención, asignaba cada problema a un responsable de desarrollo e iba remediando cada problema y probando que hubiera quedando resuelto. De esta manera proporcionamos un entorno muy visual y transparente del avance en la resolución de problemas encontrados.

La entrega

El sitio lo terminamos dos semanas antes de la fecha final de entrega y esas dos últimas semanas el cliente estuvo revisando y reportando problemas mientras nuestro equipo los resolvía. El día previo a la fecha final de entrega, alrededor de las 7:30pm terminamos de corregir todos los problemas y el sitio pudo ser anunciado en la prensa local y las donaciones empezaron a entrar al día siguiente.

Hubo algunos cambios que nos solicitó el cliente conforme iba probando el sistema y conforme veía su desempeño, pero gracias a que involucramos a nuestro equipo pudimos hacer internamente lo solicitado sin recurrir a los externos, a quienes ya habíamos liberado con la intención de no volver a contratarlos más.

Conclusión

Nos quedamos con muchas lecciones aprendidas de este proyecto, pero una de las principales es que necesitamos tomar los retos que se nos presentan, pero con una evaluación adecuada de los riesgos y de nuestra capacidad para afrontarlos. Desde luego aprendimos que debemos combinar el menor número de riesgos, por ejemplo, pudimos experimentar con un grupo de externos con los que no habíamos trabajado antes, pero en un proyecto más holgado.

Nuestro cliente quedó sorprendido por nuestra entrega a tiempo con fechas tan agresivas y un presupuesto tan recortado y gracias a eso ya estamos firmando nuevos proyectos con ellos, pero más holgados y en mejores condiciones presupuestales.

Creo que podemos hablar mucho de lo que hacemos, pero cuando nos dan la oportunidad de demostrarlo eso se convierte en el mejor argumento de ventas para nuestro equipo de trabajo. 

shutterstock_76411899.jpg

Administramos cosas, lideramos personas

Publicado el Septiembre 4th, 2013 en Integración, Recursos Humanos, Comunicaciones, General por admin

No es posible administrar a una persona, porque le reduciríamos al nivel de una cosa. La palabra correcta para decir que alcanzaremos los objetivos a través de una persona es “liderar”. Aclarado lo anterior podemos darnos cuenta que lograr los objetivos a través de la gente no es un asunto de conocimientos en administración, tecnología o negocios, sino de liderazgo, y que el liderazgo no es un asunto de efectividad, sino de eficacia. Logramos muchas cosas siendo efectivos, pero logramos los objetivos correctos siendo eficaces.

diplomados-mba-low.jpg

En una ocasión, mientras trabajaba en una empresa internacional, me tocó trabajar con un equipo que tenía integrantes de México, Estados Unidos e India. Yo era Administrador de Proyectos e invertía mucho tiempo en comunicación en todas direcciones: tenía reuniones de avance con mi equipo, creaba reportes de avance para la alta gerencia, negociaba y verificaba que nada obstaculizara el progreso del proyecto.

El proyecto iba bien, es decir, con los retos normales que conlleva un proyecto de grandes dimensiones, pero no tardé para darme cuenta de que el reto mayor no estaba en construir entregables en tiempo y costo, sino en el terreno del liderazgo de aquel equipo.

Teníamos una organización matricial. Los desarrolladores de software tenían un gerente funcional, los ingenieros de pruebas tenían a un jefe funcional y los arquitectos también tenían su propio jefe funcional. Por mi cuenta, yo tenía un equipo con recursos de las tres áreas: desarrolladores, testers y arquitectos, y para efectos de ese proyecto yo era su jefe.

Esta estructura trajo muchos beneficios, pero también muchos retos.

Una estructura matricial en la que los recursos dependen “verticalmente” de gerentes de área especializados en una función y “horizontalmente” dependen de administradores de proyectos, es una estructura flexible que requiere de mucha madurez por parte de todos sus miembros.

Algunos puntos “complicados” que he notado cuando administras proyectos en este tipo de estructuras son los siguientes:

1) Muchos jefes, poco compromiso. Cuando la gente del equipo no está acostumbrada a trabajar en una organización matricial, en ocasiones no puede ver con seriedad que su jefe es el Administrador de Proyectos en turno. Esta gente con frecuencia acude con su gerente funcional para validar si realmente tiene que hacer esto o aquello y no deja de reportarle su avance pasando por alto al administrador del proyecto. Esto complica las cosas, porque cuando hay mas de una persona a quien reportarle, el compromiso para terminar las tareas disminuye. Durante el período de vida del proyecto, los integrantes del equipo le deben reportar absolutamente todo al Administrador del Proyecto. Cuando hay algún problema con alguno de los recursos humanos, es responsabilidad del Administrador del Proyecto reportar dicho problema al gerente funcional para que éste resuelva a favor del proyecto.

2) Papá vs. Mamá. Cuando “papá” no me da permiso, corro con “mamá” y le pido permiso. Así es como muchos individuos se comportan en un esquema matricial. Cuando el Líder del Proyecto les niega algo, “corren” con su gerente funcional y tratan de conseguir el permiso. Si un gerente reacciona a favor del individuo conflictivo, la situación se torna aún peor. Se requiere mucha madurez para trabajar en un esquema matricial. El responsable de los recursos durante el proyecto es el Administrador del Proyecto, los demás niveles deben respetar esa figura de autoridad.

3) El problema de las culturas. Una persona en USA se comporta muy diferente a una de India y ésta a una de México. Cuando algunas culturas dan más libertades, otras son mas restrictivas, liderar gente de dos o más culturas siempre trae complicaciones naturales. Como Administradores de Proyecto debemos establecer un estándar de trato a las personas que faculte la igualdad pero que se adapte naturalmente a la cultura de cada país.

success.jpg Al inicio de este post hablé de liderazgo y es exactamente eso lo que se requiere para guiar a un grupo con diferentes culturas y diferentes trasfondos. Si bien la gente es lo mas valioso dentro de un proyecto, también he notado que es la gente la que provoca algunos desaciertos e incluso el fracaso del proyecto.

Liderazgo es adoptar una posición fuerte dentro del proyecto. Por favor no me malinterpreten, cuando digo “posición fuerte” no me refiero a ser el ogro o el “látigo” del proyecto, más bien me refiero a la figura que da dirección, que da certeza, que pone los engranes a moverse, que aconseja, que cuida a los recursos y que da esperanza de que todo en el proyecto va a salir bien. Ser un Líder de Proyectos es adoptar una postura “paternal/maternal” dentro del proyecto. Debes ser la persona a la cual acudir cuando algo sucede dentro de la “familia” o de sus objetivos. Debes dirimir disputas y encontrar las respuestas para que todo siga avanzando. 

Una organización matricial requiere de toda la madurez que se pueda tener por parte de los integrantes del equipo y de los gerentes funcionales, pero si esa madurez no existe, es responsabilidad del Administrador del Proyecto proveer un ambiente sano en el cual los integrantes se desarrollen y cumplan los objetivos del proyecto.

Fernando Valdez

La generación Y dentro de los proyectos

Publicado el Abril 17th, 2013 en Planeación, Integración, Recursos Humanos, Comunicaciones, General por admin

Ya hace tiempo que quiero hablar acerca de la nueva generación de empleados, aquellos que pertenecen a la llamada “Generación Y”, y pensé que éste sería un buen foro para comentar acerca de los futuros administradores de proyectos y del reto y las oportunidades que representa su presencia en nuestra profesión.

1w.jpgPrimero quisiera intentar definir quiénes son aquellos que pertenecen a la generación Y. Dije “intentar” porque en realidad no existe una definición que acote con fechas exactas cuando empieza y termina esta generación, pero es comúnmente aceptado decir que los individuos nacidos entre 1980 y el año 2000 son la generación Y. Estos son hijos de los considerados miembros de la generación X. La generación X son aquellos individuos nacidos entre 1968 y 1979 y que a su vez son hijos de aquellos conocidos como la generación de los “baby boomers”.

Sin ánimo de entrar en detalles muy lejanos a la administración de proyectos, quiero destacar algunas características del comportamiento de la generación Y. De acuerdo con diferentes estudiosos del comportamiento humano y muy en concreto de acuerdo con el Dr. Julio A. Fonseca en su participación en la 9na conferencia anual del College Board, la generación Y “se distingue por una actitud desafiante y retadora… lo cuestionan todo, no quieren leer y sus destrezas de escritura son malas… no piden permiso, ellos solo informan… no temen expresar su estado de ánimo y su principal interés no es el grupo, sino ellos mismos”. Estos comportamientos son presumiblemente motivados por la cantidad de información que ellos poseen y que puesta en sus manos les permiten retar a los mayores por tener más conocimientos y de calidad más actual.

Por otro lado, la generación Y ha desarrollado una mayor creatividad. Mientras que los baby boomers y la generación X se centran más en la lógica, la generación Y ha desarrollado un pensamiento creativo que le permite ofrecer soluciones diferentes a los problemas que se nos presentan.

Hoy en día ya empezamos a ver a la generación Y encabezando equipos de trabajo. Líderes de proyecto dinámicos y altamente sociables, que no están en un solo lugar y se adaptan a comunicaciones impersonales. Mientras las generaciones anteriores querían oficinas y definir un protocolo para trabajar todo el mes, esta generación de líderes de proyecto abrazan el cambio y saben que al final de una junta pueden haber cambios sustanciales en lo acordado. Están acostumbrados a colaborar dinámicamente y a la iniciativa de todos los involucrados.2w.jpg

Una estrategia para alcanzar los objetivos de la empresa es potencializar a sus empleados para obtener lo mejor de ellos. Considera los siguientes puntos cuando trabajes con personas de la generación Y:1. Crea un ambiente sin muchas jerarquías. Los miembros de las generaciones anteriores (baby boomers y gen X) tendemos a ser jerárquicos y a pensar en términos de “lo que dijo el jefe”. Si deseas conservar miembros de la generación Y en tu equipo de trabajo, mantén una estructura plana en la que ellos sean parte importante de la colaboración y construcción de beneficios para la compañía.

2. Capacita con ejemplos. A la generación Y le interesan las historias y no tanto la teoría sobre cómo hacer las cosas. Platícales experiencias propias, lecciones aprendidas y añade dramatismo a las conclusiones, eso los mantendrá motivados y con ánimos de hacer su propia historia dentro de la compañía.

3. Dado que la generación Y es dinámica y ha aceptado como normal la comunicación impersonal, facilítales ese tipo de comunicación. No importa que estén dentro del mismo espacio físico, la generación Y disfruta comunicarse por medio de mensajes de texto en el teléfono, inbox, mensajeros, etc. Incorpora ese nivel de digitalización en las comunicaciones del equipo aún y cuando a ti te parezca un medio informal, recuerda, ellos están concentrados en el contenido, no en los medios por los que les llega dicho contenido.

4. No pongas a la generación Y a aprenderse un manual de usuario y no esperes que, aun teniéndolo frente a ellos, vayan a optar por abrirlo antes que saltar y hacer una pregunta. La generación Y no busca teoría, busca experiencias. Es más común ver a la generación Y buscando en medios que nosotros consideramos informales como lo son los blogs y listas de discusión, que abriendo un libro o un diccionario. Si llegaran a buscar alguna definición, ellos prefieren la Wikipedia que un diccionario. La generación Y “googlea” sus dudas.3w.jpg

5. Si es posible, cambia continuamente de rol a los miembros de la generación Y. Nosotros (los baby boomers y la generación X) creemos en la especialización, pero esta es la receta para desmotivar a la generación Y. Aún y cuando también la generación Y ha logrado muy exitosamente dominar aspectos muy específicos de su profesión, ellos no quieren estar quietos y especializarlos es exactamente eso.

No cabe duda de que tenemos un reto delante de nosotros. Hoy en día los baby boomers ocupan puestos directivos en nuestras empresas mientras la generación X ha tomado muchos puestos de gerencia alta e intermedia, sin embargo la generación Y ha llegado, ascendiendo cada vez más alto en los organigramas y su presencia está cambiando la forma en que las empresas administran sus proyectos.

Aprovechemos esta nueva fuerza laboral. Ajustemos nuestros planes de comunicación para que sean más efectivos y para que alcancemos los objetivos del proyecto que, a final de cuentas, es para lo que somos líderes de proyectos.

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.