Archive for the ‘Tiempo’ Category

Aceptando el reto

Jueves, Marzo 19th, 2015

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

Planeando el año nuevo

Lunes, Diciembre 12th, 2011

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

El tiempo en el proyecto

Jueves, Diciembre 2nd, 2010

time-management.jpgEn una ocasión me invitaron a participar en un curso sobre liderazgo en el que los instructores serían el director de capacitación para Latinoamérica y el director de capacitación para Europa, África y el Este medio dentro de nuestra compañía. Ellos eran de nacionalidad mexicana e inglesa respectivamente. Ambos directores eran muy diestros en el área de liderazgo y técnicas de capacitación.

 

El plan del curso estaba muy bien construido y nos fue comunicado al inicio del primer día. Los directores se habían organizado para cubrir los temas alternando sus intervenciones, es decir, un tema lo cubría uno de ellos y otro tema el otro y así sucesivamente. A la hora de la comida del primer día me di cuenta de que la agenda no estaba siendo cubierta de acuerdo al plan y como buen Project Manager empecé a preguntarme ¿cómo le harían para terminar a tiempo?, ¿recortarían el alcance del curso (proyecto)? Desde luego que no había la opción de fast track ni de utilizar la técnica de crashing del cronograma, ¿como le harían?.

 

Más aún, con ánimo de dar con la causa raíz del problema me puse a pensar, ¿que provocó ese retraso de tiempo? Dado que no era mí proyecto no me había puesto a pensar en eso, pero me pareció interesante. Me puse a observar el desempeño de ambos directores con más detalle y pude observar como el instructor de nacionalidad inglesa cumplía cabalmente con todos sus compromisos de tiempo sin menoscabo de calidad. Por otro lado, el instructor mexicano era muy cálido y anecdótico, pero siempre y subrayo siempre terminaba a destiempo. Incluso, en ocasiones en que el instructor inglés estaba en su exposición, el mexicano interrumpía para aclarar algún punto que no tenía ningún sentido aclarar, entorpeciendo así el progreso del curso.

 

Por favor no me malinterpreten, yo soy mexicano y de ninguna manera “malinchista”, simplemente quiero dar fe de mis observaciones.

 

Al final del primer día pude observar que algunos de los temas que estaban planeados no se cubrieron en la capacitación y pensé que probablemente se cubrirían el segundo día, sin embargo no fue así, los directores recurrieron a un recorte del alcance de su proyecto y a sacrificar la calidad de algunos entregables para cumplir con la restricción de tiempo que ellos mismos se provocaron.

 

¿No les ha pasado algo parecido en sus proyectos?

 

El segundo día de capacitación, cerca del final del día me acerqué al instructor de Inglaterra quien parecía preocupado y le pregunté que ocurría y desesperado  me comentó que el mes anterior dieron ese mismo curso en Jamaica y que no entendía por qué en México las cosas llevaban mucho más tiempo. Más allá de concentrarme en la efectividad de los conferencistas o en criticar sus prácticas me quiero concentrar en el tema del tiempo.

 

Muchas ocasiones he asistido a conferencias en que se habla de administración del tiempo, nosotros mismos hemos usado el término que, a final de cuentas, es un término errado. No es posible administrar el tiempo, es un intangible que no podemos detener o poner más aquí y menos allá. Lo que podemos hacer es administrar nuestras actividades a través del tiempo, administrarnos a nosotros mismos.

 

Cuando se nos delega la responsabilidad de ser el líder del proyecto, automáticamente nos están delegando responsabilidad sobre diversos aspectos, pero uno de los más importantes es el tiempo.

 

El líder de proyectos necesita ser puntual, es una de sus banderas, una de sus armas, es una de sus responsabilidades  y uno de los factores por el cual es calificado. No veo a un líder de proyectos llegando tarde a una reunión de trabajo ni saliendo tarde de una junta. No veo a un líder de proyecto haciendo perder el tiempo a su equipo en largas, mal planeadas o impuntuales juntas. Estuve en una compañía en donde el tiempo parecía un recurso ilimitado: infinidad de juntas y pocos acuerdos, todos llegaban tarde y aun esperábamos a que todos estuvieran en la reunión. En una ocasión, un gerente de servicio a clientes entrando a una junta que yo había organizado me dijo “¡Qué bueno que te veo, ¿por qué no está funcionando este módulo del sistema? Mi gente entra, da click y ¡sólo recibe información equivocada!…” puedo escribir 100 líneas más acerca de sus comentarios, todos llegaron a la junta y este individuo continuaba hablando, lo hizo por 20 minutos hasta que terminó diciendo “¿eh? ¡Explícame! ¡No entiendo por qué ocurre eso!”. Debo confesar que me sacó de mis cabales. Yo era un líder de proyecto experimentado en el área técnica, pero inexperto tratando con gente y mi primer respuesta fue “Gilberto, ¿cómo quieres entender hablando? Si te callaras y me escucharas podría explicarte qué es lo que está pasando”. Todos los asistentes se rieron a carcajadas porque conocían la costumbre de acaparar reuniones de este gerente (cuyo nombre real desde luego que he cambiado). No me enorgullezco de mi respuesta, pero logré mi objetivo.

 

El líder de proyectos es el dueño del tiempo del proyecto, debe ser agresivo e inflexible con él. Con esto no quiero decir que no debe dar lugar a cosas importantes como un tiempo para dar gracias o para hacer “team building”, pero aún estas son actividades del proyecto que deben estar planeadas o tener algún grado de improvisación controlado. Un funcionario, el dueño del proyecto o un ejecutivo de alto nivel no pueden acaparar el tiempo del proyecto porque tal derecho (o poder) se le otorgó al líder del proyecto (mediante el Project Charter) para administrarlo adecuadamente. Al final esos ejecutivos no pedirán cuentas sobre el uso del tiempo, ni se les va a entregar en una cajita todo el tiempo que sobró. Al final ellos esperan resultados dentro de los límites estipulados de tiempo.

 

Finalmente, el líder de proyecto no debe temer ser criticado por el hecho de ser agresivo con el uso de su tiempo y del de su equipo, al final del día acudimos al trabajo a ser efectivos y a ganar buena reputación profesional para prepararnos para nuestro siguiente reto y, en última instancia, para asegurar el sustento para nuestra familia. Conozco el caso de una persona que invertía más tiempo haciendo amigos en el trabajo y justificando su bajo desempeño que haciendo el trabajo mismo. Cuando lo despidieron de la compañía sus “mejores amigos” no pagaron sus cuentas de luz, agua, gas, renta, colegiaturas, etc.

 

El tiempo es importante. Administrarnos y administrar nuestro proyecto lo es aún más. El tiempo es vida. Piensa dos veces antes de pedirle a alguien 10 minutos para escucharte, porque en última instancia le estás pidiendo que dedique un pedazo de su vida en ti; haz que valgan la pena esos 10 minutos para ti y para él/ella.

 

Por Fernando Valdez

El don de la omnipresencia y la dilatación del tiempo

Miércoles, Enero 16th, 2008

omni.jpgRevisando el trabajo de varios involucrados en el proyecto (stakeholders) encontré varios retrasos en las entregas de algunos, por supuesto que me preocuparon estos retrasos ya que impactarían en el proyecto, apelé al sentido de responsabilidad de los retrasados sin obtener resultados en la mayoría de los casos, hasta que una de las involucradas (esa que existe en todas las empresas y se sabe las historias de tod@s) me comentó que no pidiera milagros, que sus jefes los tenían trabajando de sol a sol, debido a la reciente compra de la empresa por una trasnacional, todos estaban bajo auditoría y tenían que entregar enormes reportes a los auditores, además de atender las necesidades de nuestro proyecto (que no eran pocas) y por si fuera poco también tenían que cumplir con su trabajo normal. Pero eso no es todo, también cambiaron las políticas de recursos humanos y a todos les avisaron que tenían un mes para tomar las vacaciones pendientes, en caso contrario esos periodos vacacionales caducarían. Después de esta explicación entendí la causa de casi todos los retrasos en las entregas, es ingenuo esperar que alguien cumpla con su carga normal de trabajo, dos proyectos extras y al mismo tiempo tome las cuatro semanas de vacaciones que le debía la empresa. Vamos, nadie va a poder cumplir con todo eso a menos que tenga el poder de la omnipresencia para estar en varios lugares al mismo tiempo, o que sepa cómo dilatar el tiempo para hacer que los días duren 30 horas. Opté por hablar con el patrocinador del proyecto indicándole las serias contradicciones que tenían con respecto a las políticas de recursos humanos y cómo afectarían al proyecto, me dijo que lo comentaría con la dirección para saber qué podían hacer, sinceramente espero encuentren una buena solución.

Moraleja…

Reconozcámoslo, hasta el momento nadie ha podido retrasar el tiempo, ni aparecer al mismo tiempo en dos lugares, creer en la omnipresencia o en congelar el tiempo es tan ingenuo como pedirle a alguien que haga el trabajo de cuatro personas. Lo mejor es ser realista y reconocer las limitaciones del tiempo y el espacio para lograr un proyecto exitoso.

Por Mentat