Archive for the ‘General’ Category

Un proyecto en aprietos

Martes, Marzo 15th, 2011

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

¿Tú como project manager cultivas tu cultura general?

Martes, Noviembre 9th, 2010

“Era una delicia platicar con ellos. Podías pasar una tarde muy amena y los temas relacionados con geografía, historia, política, arte entre otros, fluían de manera natural y escurrían virtuosamente de la boca de aquellos médicos. Eran una generación preparada, ellos habían ido más allá de su llamado vocacional y se habían convertido en personas cultas y, desde luego, los mejores practicantes de la medicina en cada una de sus especialidades”. Esa fue parte de la nota de apertura en un congreso nacional de medicina que aglutinaba médicos de varias especialidades y en la que se hacía referencia a una generación de médicos de los años 70s, un grupo de especialistas médicos que ejercían su profesión, pero más allá de sus amplios conocimientos en su especialidad mostraban un gran conocimiento de la sociedad y del funcionamiento del mundo en el que ellos vivían.

No, no me equivoqué de foro, estoy escribiendo para LiderDeProyecto.com, estoy consciente de eso. Traigo a colación ese tema porque me pregunto, ¿cuántas veces he escuchado ese comentario en alguna reunión de Project Management?

null

La cultura general en la Administración de Proyectos

Como Líderes de Proyectos necesitamos cultivar una cultura superior a la de los practicantes de muchas otras disciplinas. Algunos dicen que PM (Project Manager) son las iniciales de People Manager (Administrador de Gente) y eso no está muy alejado de la realidad. Cuando se trata con personas afrontamos un sinnúmero de circunstancias que nos obligan a cultivar una mayor cultura. En mi experiencia como líder de proyectos he tenido que tratar con temas de matrimonio de la gente que me reporta, trabajo, situaciones familiares, religión, costumbres, viajes, vacaciones, motivación, etc. Cada día tengo la oportunidad de tratar con una nueva situación. He tenido gente delante de mí con situaciones realmente conmovedoras y otros con situaciones divertidas o afortunadas, y es imposible tratarlas con la misma ‘técnica’.

No se diga si administras un equipo virtual. Es necesario conocer fechas especiales en el calendario de aquellos que están trabajando remotamente a tu oficina, celebraciones religiosas y diferencias culturales son áreas con las que he tenido que tratar en más de una ocasión.

En China las personas no sienten que han llegado a un nivel aceptable de involucramiento si sólo se atienden asuntos laborales, ellos esperan compartir situaciones personales incluso al punto de preguntar abiertamente cuál es tu compensación económica mensual. En India aquellos varones que son muy amigos se sienten libres de caminar por la calle abrazando a su amigo (otro varón) sin sentir vergüenza o miedo de ser discriminados socialmente. En México acostumbramos a tocar temas personales en el ambiente laboral. En Estados Unidos puedes rechazar fácilmente una invitación diciendo ‘ya tengo planes’. Como estos hay muchos ejemplos que existen de la diversidad cultural en el mundo y de los que debemos estar conscientes si es que nos corresponde.

Aspectos culturales que debe conocer un Project Manager

Vamos a lo práctico: ¿qué es lo que se supone que deberías saber? Para contestar esta pregunta necesitas responder a otras tantas, como: ¿qué características tiene tu proyecto?, ¿quienes son tus clientes?, ¿quienes son los miembros de tu equipo?, ¿en qué industria se desarrolla tu proyecto? Aquí quiero hacer un alto. Dicen que la pregunta más antigua en Project Management es ¿qué es mas importante para un PM, ¿conocimiento de la industria o conocimiento de Project Management?? La respuesta que ha ‘vendido’ el PMI (y no me malinterpreten, yo soy PMP certificado por el PMI) es que necesitamos conocimiento de Project Management y no discuto con la necesidad de esos conocimientos, pero creo que tenemos que desarrollar un amplio conocimiento de la industria en la que nos desempeñamos para poder completar el bagaje de competencias que nos ayuden a conducir un proyecto al éxito.

¿Has contestado alguna de las preguntas que hice en el párrafo anterior? Si es así entonces estás empezando a distinguir algunas áreas que dominas y otras que no lo has hecho del todo bien.

Para hacer las cosas más fáciles termino con una lista de aspectos necesarios por dominar:

  • Computación (saber usar un procesador de palabras, hoja electrónica de cálculo y software para presentaciones)
  • Redacción (al menos redacción de reportes técnicos)
  • Ortografía (al menos la de las palabras mas usadas en la jerga de PM)
  • Liderazgo
  • Delegación de tareas
  • Un segundo idioma (aquel que se requiera más en tu área de desarrollo)
  • Geografía (como mínimo la local y los países vecinos)
  • Zonas horarias (por lo menos ubicar al meridiano de Greenwich y la(s) que le corresponde(n) a tu país y al de tus clientes y colaboradores
  • Historia (es impresionante la cantidad de preguntas que he recibido de todo el mundo con respecto a nuestra historia de México. En ocasiones me he topado con extranjeros que conocen mejor nuestra historia que nosotros mismos)
  • Política (por lo menos los sucesos más conocidos internacionalmente, locales y extranjeros)

Como habrás visto la lista anterior no es exhaustiva y me encantaría que en los comentarios de retroalimentación a este post tú nos apoyes con tus opiniones y tu propia experiencia. Quizás mi última recomendación acerca de la cultura general que debe tener un líder de proyectos es la siguiente: nunca es tarde para incrementar tu acervo cultural: enrólate en una capacitación este mismo mes, este semestre, este año, no lo dejes pasar, el tiempo no regresa.

Por Fernando Valdez

“Entregar” como una filosofía de trabajo

Jueves, Septiembre 30th, 2010

Nuestra filosofía es hacer lo que dijimos que íbamos a hacer. Nuestra filosofía es “nosotros entregamos”. Sin peros, simplemente nosotros entregamos. Entregamos lo que dijimos que entregaríamos. No menos. No de menor calidad. Ni un día después. Lo que pase tras bambalinas es nuestro asunto, no es asunto del cliente, no nos hacemos los mártires. No hacemos que el cliente sufra nuestras carencias o defectos. Para nuestro cliente cada individuo representa la compañía y el desempeño que mostremos es la imagen del desempeño que el tendrá de la compañía. Cuando ellos se llevan una experiencia buena no mencionarán mi nombre, ellos simplemente recomendarán trabajar con nuestra compañía.

Si yo entrego a tiempo está bien, no merezco ninguna medalla porque simplemente me pagan por hacer eso. Ellos no me pagan para ser buena gente ni me pagan por hacer mi mejor esfuerzo… la expectativa que tienen de mí es que entregue lo que me comprometí a entregar.

Estábamos a punto de iniciar un proyecto en la compañía que recién nos acababa de contratar. Se trataba de un experimento, la compañía había recibido referencias de que en México podría encontrar mano de obra barata y con una cultura similar a la de los estadounidenses y teniendo base en la ciudad de Dallas, Texas la compañía podía ver adicionalmente la ventaja de encontrarse a menos de hora y media de la ciudad de Monterrey y en la misma zona horaria.

Así que contrataron desarrolladores de software, ingenieros de calidad, arquitectos y a un servidor como Project Manager. Debo confesar que hasta entonces y por más de 10 años había jugado el rol de Líder de Proyectos y Coordinador de Proyectos, pero nunca había sido totalmente ‘accountable’ (la traducción literal en español es ‘responsable’, pero este término en español no describe totalmente lo que la palabra accountable quiere decir para los Norteamericanos, en pocas palabras accountable quiere decir que ‘tu cabeza rodará si algo sale mal’) del éxito o fracaso de un proyecto. No quiero decir que como Líder de Proyectos no tengas ese nivel de responsabilidad, lo que digo es que en México la estructura predominante en las compañías es Funcional y si bien los Coordinadores, Jefes y Líderes tienen responsabilidad, la verdad es que los Gerentes Funcionales y Directores cargan con más de esa responsabilidad, cosa que no es así en Estados Unidos.

Como sea, estábamos empezando el proyecto y muchos compañeros de Estados Unidos me comentaron lo grande e importante que era ese proyecto pero nunca pensé que sería tan retador. A pocas semanas de haber sido asignados ya nos encontrábamos llenos de trabajo y haciendo esfuerzos más allá de lo posible para alcanzar los objetivos propuestos en el tiempo indicado. Habíamos sufrido un cambio en la arquitectura del sistema cuando ya llevábamos un valor ganado del 50%, de tal forma que mucho trabajo se desperdició (en otro post les compartiré cuál fue la razón de la re-arquitectura). Finalmente, el cliente preguntó si tendríamos completado el alcance para la fecha indicada y, acostumbrado a una filosofía del “no se puede”, esperaba que el Vicepresidente de Tecnología, a sabiendas de todos los esfuerzos que estábamos haciendo, dijera que no veía factible nuestra entrega, se limitó a mencionar la cantidad de retos que nuestro grupo había superado y que estaba seguro que podríamos continuar con esa racha para entregar en la fecha en que prometimos entregar.

Al principio esto me sonó a explotación y pensé que había sido la respuesta incorrecta, después de todo, los gerentes y directores con los que había trabajado antes se conformaban con un “necesito más tiempo”, “necesito más recursos”, “recórtame el alcance del proyecto” o cualquier otra forma de estas tres excusas anteriores. Me dolía la mente de sólo pensar en esa respuesta, pero lo que estaba ocurriendo en mi mente en realidad es que se estaban rompiendo paradigmas… y eso dolía.

No quiero confundirlos diciendo que tenemos que esclavizarnos en el trabajo cuando la culpa no es nuestra, pero afrontémoslo, vivimos en una cultura de esfuerzo mesurado y cualquier cosa que amenace los límites que hemos impuesto se convierte en un enemigo. Creo firmemente en la calidad de vida, en la socialización y en el balance entre trabajo y familia, pero también creo en el esfuerzo, aunque de vez en cuando este tenga que retar nuestros propios límites. Cuando un músculo es llevado al límite de lo que puede cargar, las fibras musculares se rompen y “aprenden” que, si crean una fibra igual de resistente, nuevamente se volverá a romper y entonces “deciden” hacer una fibra más gruesa, una cicatriz abultada de músculo que les permita resistir más peso… eso duele, pero genera un crecimiento del músculo y, por ende, un crecimiento en la capacidad de carga. Al mismo estilo mi mente dolió pero en lugar de pensar en formas para evitar el trabajo empecé a ser creativo para lograr, por medio de la gente, todos los objetivos en el tiempo indicado.

Al final terminamos el proyecto a tiempo. Tuve que negociar diferentes cosas con cada uno de los miembros de mi equipo. Yo era el primero en llegar y nunca me fui de la oficina antes que ellos, me levantaba de mi lugar con frecuencia para ver si podía ayudar en algo al equipo local y tenía llamadas a USA por horas para coordinar esfuerzos con el equipo de allá (estaba virtualmente allá). Iba por la pizza en la noche y por el café en las mañanas, nunca dejé a mi equipo solo… después de todo ellos harían que esa hazaña fuera una realidad.

Si adoptamos esta filosofía de trabajo nuestra reputación como alguien que entrega se incrementa y esto se traduce en más y mejores proyectos, proyectos con mayor complejidad, proyectos de mejores clientes, proyectos para crear productos, servicios o resultados únicos. ¿Cuál es el beneficio de esto? Bueno, si eres una persona que sabe invertir a mediano y largo plazo entonces ya puedes empezar a pensar en los grandes beneficios que esta filosofía puede traer más allá de la satisfacción personal y aumento de nuestra autoestima profesional: Nos hará aspirar a mejores oportunidades de empleo.

Poco después hubo un cambio en la estructura organizacional y la Oficina de Proyectos a la que yo le reportaba fue movida a otra rama de la compañía. Recibí una llamada del Vicepresidente de Tecnología diciéndome que tenía planes de expansión para el equipo de México al grado de cerrar cada posición técnica en USA e India y mover todas las operaciones técnicas a nuestra ciudad.  Pero lo mejor de la llamada fue la oferta que me extendió para ofrecerme quedarme al cargo de todo el grupo y no sólo de un equipo de proyecto. Yo le argumenté que mi especialidad eran los proyectos y que hasta una certificación de PMP tenía, pero que el manejo de gente, comunicaciones  y cuestiones administrativas no era mi fuerte y el sólo dijo, “lo sé, pero tú ‘entregas’, eres un gran líder”.

No importa si estás al cargo de grandes proyectos técnicos o pequeños proyectos administrativos, cuando tu filosofía de vida es “entregar no importando qué”, la imagen que los demás tienen de ti se eleva y todos saben que ese patrón de éxito puede repetirse en futuros proyectos y/o en futuras posiciones de mayor responsabilidad.

Por Fernando Valdez

Líderes de Proyecto radicales

Martes, Agosto 31st, 2010

lider_radical.jpgHe conocido gente exitosa en el área de Project Management y puedo decir que todos comparten una característica en común: toman decisiones radicales en sus proyectos y no son indulgentes.

Permítanme explicar un poco mejor. Un administrador indulgente es aquel que es permisivo y laxo al perseguir sus metas. Traza planes pero frecuentemente pierde la visión original del proyecto. Permite que el ambiente y/o personas a su alrededor manejen la agenda o modifiquen el alcance de su proyecto. No estoy diciendo que un plan debe estar escrito en piedra, entiendo que para eso existen herramientas que nos permiten actualizar el “baseline” del proyecto y que por eso existe el concepto de “change process” dentro de la jerga de administración de proyectos, pero una cosa es administrar los cambios y otra es permitir que otros manejen su agenda y hagan los cambios que les parezca convenientes sin tomar la opinión del Líder del Proyecto.

Por el contrario, los administradores exitosos son personas flexibles al cambio y sensibles a las opiniones externas pero dejan muy en claro quién es el responsable del proyecto y en ocasiones toman decisiones radicales que pudieran parecer impopulares pero que favorecen el avance del equipo hacia la consecución de la meta original.

Hace poco experimenté las consecuencias de una decisión radical. Quisiera decir que yo tuve la iniciativa pero les estaría mintiendo, yo no tomé esa decisión; de hecho mi familia y yo sufrimos las consecuencias de esa decisión por más de un año y medio, pero al final pude extraer algunas lecciones de esa experiencia.

Experiencia

Trabajo para una compañía estadounidense que hace unos años se fijó una meta: ser una organización de 10 billones de dólares americanos para el año 2010. En ese entonces la compañía valía poco menos de 6 billones de dólares y la fecha trazada por nuestros propios ejecutivos se estaba acercando. La empresa recurrió a diferentes métodos para alcanzar su meta como lo fue la compra de otras compañías, la reducción de costos, la contratación de personal fuera de los Estados Unidos (off-shore), etc. Aún con estos esfuerzos la meta seguía lejana y fue allí cuando decidieron tomar una decisión radical.

En aquellos días yo era Project Manager de tecnología y pertenecía a un grupo reducido de empleados en México, pero los esfuerzos por alcanzar la meta de la compañía obligó a mi unidad de negocios a expandirse en México mientras reducía a su personal en Estados Unidos. Dado que una mayor cantidad de empleados demanda una administración más formal fui promovido a Administrador General de mi unidad de negocio para la oficina de México. Recibí el nombramiento y la carga de trabajo, pero en el momento en el que iba a recibir mi incremento de salario los ejecutivos de la compañía tomaron la decisión de congelar todo tipo de incrementos salariales con el fin de alcanzar la meta de los 10 billones de dólares. La cantidad de trabajo no se dejó esperar, las fechas límite empezaron a cumplirse y en pocos días yo estaba administrando una unidad de negocio mas allá del doble de lo que medía cuando yo era PM.

Todo creció… menos mi salario. Empecé a pensar que era injusto e incluso pensé que me habían engañado, que sólo me iban a dar la responsabilidad pero no el incremento. Confieso que en innumerables ocasiones busqué empleo en otras compañías y hasta busqué irme por la misma compensación que ya estaba recibiendo sólo con el objetivo de salirme de aquella compañía que no me había cumplido.

Mi jefe en Estados Unidos insistía en que quería retenerme y ya había conseguido la autorización (para mi incremento) de su jefe y del director ejecutivo de nuestra unidad de negocio, pero al parecer la orden de congelar los salarios venía desde mucho más alto.

Yo seguí trabajando y dando lo mejor de mí, no quería que nada influyera en la decisión de mi aumento una vez que los salarios fueran liberados, y a la vez ninguna oferta “allá afuera” era tan buena como la que tenía actualmente.

Un año después de congelados los salarios la compañía anunció que sería vendida a una compañía mucho más conocida que la nuestra. Para inicios de 2010 nuestra compañía había alcanzado su objetivo de ser una compañía de 10 billones de dólares (de hecho de 11 billones de dólares) y los incrementos de sueldo fueron liberados para todos aquellos que teníamos una promesa sobre la mesa.

En el proceso muchos buenos elementos salieron de la compañía porque no habían recibido lo que les habían prometido. En mi unidad de negocios ocurrió que uno de nuestros empleados “estrella” recibió una oferta y “amenazó” con salir de la compañía. Yo urgí a mi jefe para que hiciéramos algo porque no podíamos darnos el lujo de perder quizás al mejor elemento que teníamos, pero la respuesta fue negativa. Finalmente perdimos a un muy buen elemento y, en su momento, nos dolió profundamente, pero para ser franco debo decir que a la larga la pérdida que sufrimos no causó estragos en nuestra unidad de negocios y menos en nuestra compañía. Renunciamos a un bien menor por obtener uno mayor.

Decisiones radicales en Project Management

Hay proyectos que fracasan por cambios continuos en el alcance y nuestro rol como Líderes del Proyecto queda reducido a la de un coordinador de operaciones diarias que tiene que entregar reportes semanales de progreso y muchos más reportes relacionados con las operaciones del equipo de trabajo.

Nuestra labor diaria debería incluir la toma de decisiones radicales en beneficio del proyecto. Debemos saber tomar decisiones radicales con respecto al presupuesto, con respecto al alcance y con respecto al tiempo de entrega. Estas decisiones pueden ser impopulares de momento, pero es lo único que nos puede ayudar a concluir nuestros proyectos de la manera planeada.

Para cumplir los hitos (milestones) del proyecto necesitamos ser radicales en el uso del proceso de aceptación de cambios (change request process), necesitamos ser radicales en la entrega a tiempo. Necesitamos aprender a negociar y a congelar los cambios solicitados y aprender a versionar nuestros productos.  Se requiere saber decir “no”. Se requiere saber decir “hasta aquí”.

Si tomamos decisiones radicales es probable que algún entregable quede fuera del alcance del proyecto y es probable que haya uno o dos patrocinadores molestos con nuestras decisiones, pero el objetivo del proyecto (que ellos mismos están patrocinando) se habrá cumplido en los términos solicitados y podrán empezar a recibir sus beneficios.

Principios para la toma de decisiones radicales

Quiero compartir algunos principios para tomar decisiones radicales pero racionales que ayuden a la consecución del objetivo de sus proyectos:

  • Necesitamos entender que cualquier proyecto es importante. No necesita ser el proyecto más grande de la compañía para esforzarnos por terminarlo en forma. Si somos indulgentes en lo pequeño, lo seremos en lo grande.
  • Necesitamos aprender a decir “hasta aquí” y “no” de manera amable. No tengas miedo a tomar decisiones “muy sonoras” o impopulares siempre que un análisis costo-beneficio te dé la razón.
  • Si eres el Líder de un proyecto y no puedes decir “hasta aquí” en realidad no eres más que un “chivo expiatorio” al que le pueden echar la culpa cuando el proyecto fracase. * * Haz que los ejecutivos o los clientes firmen un Project Charter en el que se te otorgue la responsabilidad del proyecto, pero también la autoridad de tomar decisiones que beneficien al proyecto.
  • Probablemente vaya a haber “bajas de guerra” pero no te acobardes. El miedo no es razón para cederle terreno al fracaso. Antes de tomar una decisión radical haz un análisis “What if…” donde consideres los mejores y los peores escenarios y una vez tomada la decisión llévala hasta el límite: alcanzar el objetivo.

Conclusión

No conozco ningún gran logro que se haya hecho sin esfuerzo ni ningún proyecto exitoso en el que no haya habido necesidad de ser radicales con respecto al alcance y/o al tiempo. No conozco un logro importante que no haya involucrado el trato con gente y en ocasiones hasta confrontación del Líder del Proyecto con más de uno de los interesados en el proyecto.

Pensar alcanzar una gran meta sin esfuerzos ni confrontaciones es ingenuo.

Por Fernando Valdez

Perdidos por dejar de ver el horizonte

Jueves, Octubre 15th, 2009

para-el-blog.jpgConocer el detalle del árbol sin dejar de pensar en la perspectiva del bosque es importantísimo, de lo contrario puedes andar dando tumbos perdido en las particularidades, olvidando cumplir los objetivos realmente importantes del proyecto.

Hace algunos proyectos alguien me preguntó si sabía cómo configurar los permisos de instalación en el servidor del proyecto, le ayude a resolver el problema y un par de días después me comentó con un poco de urgencia que llevaba dos días intentando saber cuáles eran los puertos que estaban abiertos en la red, medio día después y con la ayuda del todo-poderoso administrador del sistema los puertos que necesitaba quedaron abiertos.

El lunes de la semana siguiente le pregunte si ya estaba todo listo para la auditoria de calidad que nos harían y angustiado respondió que no, lo único que faltaba era contar con un repositorio del proyecto donde llevar el control de versiones, y no estaba listo porque había tenido muchos problemas resolviendo los permisos de instalación, abriendo puertos, consiguiendo versiones de prueba del software de control de versiones y luego reinstalando la versión que se compró y que además eso había ocasionado un retraso de varios días en sus tareas del proyecto.

Ese fue uno de los mejores ejemplos de alguien que se pierde en los detalles del árbol y pierde la perspectiva del bosque, se centró demasiado y perdió varios días en los detalles del problema de instalar el software de control de versiones, cuando esa no era la única opción para realizar esa tarea.

El objetivo de ese punto de revisión en calidad era llevar un control de versiones y tener un repositorio donde todo mundo puediera encontrar la documentación del proyecto, y no era el de instalar un software para automatizar el control de versiones. La auditoria la pasamos sin problemas, el repositorio fue la carpeta del proyecto apegada a la estructura del proceso y para el control de versiones al nombre de cada archivo le agregamos el numero de la versión. No fue la mejor solución pero cumplía el requisito. Si hubiera hecho esto desde el principio no habría tenido ningún retraso en sus tareas del proyecto.

Moraleja…

En un proyecto nunca pierdas de vista el objetivo de la tarea que estás realizando, concentrarse en los detalles y olvidar qué es lo que quieres lograr te puede llevar al fracaso del proyecto, a esto se le conoce como “Perderse en los detalles del árbol y perder la perspectiva del bosque”, los detalles son importantes, siempre y cuando no pierdas la visión que te da un enfoque completo.

Por Mentat

¿Estás en las penumbras o en la luz?

Lunes, Mayo 18th, 2009

El tic-tac del reloj sonaba con la fuerza que uno percibe después de una noche de vigilia, sólo el cálido sabor del café y el frío del alba me mantenían despierto.  Tenía razón ese viejo lobo de los proyectos que me recomendó en cada desvelo, subir a la azotea y contemplar el amanecer al menos durante media hora para reflexionar y recapacitar sobre el rumbo del proyecto.

Los días de descanso obligado por la epidemia de influenza  humana fueron necesarios, pero afectaron en varios aspectos al proyecto y revelaron cosas interesantes.

El descanso preventivo por enfermedad de un par de líderes de grupo, evidenció dos estilos de administración diferentes, ambos grupos de trabajo entregaban resultados, pero en la contingencia el primer equipo estaba como un gallinero con un zorro dentro, todo mundo corriendo de un lado para otro como locos y sin saber qué hacer. Su líder desde hace tiempo se regodeaba diciendo “si no estoy, nada funciona”, nadie le creía, pero yo sé que es una triste realidad, y no es porque su equipo de trabajo sea incapaz, ya que tiene personas competentes, pero nunca les transmite el objetivo general de lo que están haciendo, únicamente les entrega actividades aisladas, y es como si trabajaran a ciegas, por eso cuando el líder faltó, nadie en su equipo sabía qué hacer, con qué tareas continuar, a quién entregarle el trabajo. Sospecho que este líder mantiene a su grupo en penumbras por miedo a que alguien sobresalga más que él o para que la empresa no piense en despedirlo.

El segundo equipo de trabajo por el contrario estaba trabajando a un ritmo intenso, pero todos tenían una mirada de saber hacia dónde dirigirse y qué hacer. El líder de este equipo le había transmitido a todo su personal los objetivos, alcance y tiempos. Cada uno sabía qué parte del trabajo debería realizar y qué seguía.

En ese momento recordé una viejísima anécdota de un militar que aleccionando a sus pupilos, les decía que un buen ejército es aquel donde todo soldado sabe la estrategia general y los objetivos de la batalla, porque en medio del combate es frecuente que se pierdan las comunicaciones y que se tenga que cambiar la táctica para lograr los objetivos, en un escenario así un soldado bien informado sabe qué improvisar para apoyar los objetivos generales de su ejército.

En el segundo equipo de trabajo todos los integrantes estaban bien informados, en ausencia del líder, durante los días de trabajo en casa con comunicaciones limitadas, supieron cómo cambiar la táctica para conseguir los objetivos.

Moraleja…

No hay duda, en tiempos de crisis se ve quién está mejor templado, todo mundo ha entendido que el líder oscurantista tal vez cumple con el trabajo y es indispensable para que las cosas funcionen, en cambio el líder que comparte la visión e informa a su equipo es el estratégico para el proyecto. En la evaluación para ascender al siguiente nivel de responsabilidades es claro que prefiero alguien que sea estratégico y genere equipos de trabajo funcionales antes que alguien que es indispensable pero que tiene equipos de trabajo dependientes y disfuncionales en su ausencia.

Por Mentat

Cómo decidir qué dejar de hacer

Martes, Abril 14th, 2009

Hace algunos días escuche a alguien decir:

“Sí, era importantísimo, pero ya no nos dio tiempo de hacerlo”

Y como un déjà-vu acudieron a mi mente los recuerdos de tantas noches corrigiendo errores porque a alguien se le olvidó o no tuvo tiempo de hacer el trabajo planeado. ¿A algun@ de ustedes le trae recuerdos la frase “ya no nos da tiempo de diseñar, vamos a construir sin el diseño completo”?

Cuando esto comienza a suceder es que el proyecto se está administrando por reacción y no por planeación, y en un proyecto existen pocas situaciones peores que hacer las cosas sin planeación. Es como cuando en un partido de fútbol todos corren como locos detrás de la pelota en lugar de seguir una táctica planeada.

Seamos realistas y reconozcamos que un altísimo porcentaje de los proyectos se retrasan con respecto a lo planeado, siempre hacemos lo posible por evitar caer en esta situación, pero si ya te encuentras en un escenario similar, entonces es importante saber cómo reaccionar, el error usual es instalarse en la urgencia y hacer sólo lo que nos dio tiempo, pero aunque suene un poco raro, también se debe planear qué dejar de hacer, la mejor forma de remontar una situación así es analizando las consecuencias de no hacer cada actividad, priorizar las actividades de acuerdo al impacto de cada omisión y así tenemos nuestra lista de actividades que debemos atender primero.

En una reunión post-mortem de uno de los proyectos de mis años mozos, el líder de proyecto reconoció: “Al principio no llevamos el control de riesgos porque ya no nos dio tiempo, pero después de la inundación aprendimos que eso fue lo peor que pudimos hacer”. Esa fue una lección aprendida a la mala, por cierto, en ese proyecto también se robaron varias computadoras con información importantísima, no cabe duda que hay proyectos con mala suerte, pero eso de los riesgos es otra historia.

Moraleja…

Por supuesto que lo ideal en un proyecto es planear todo bien y no entrar en una dinámica de todo urge y tiene que estar para ayer, pero cuando el destino nos alcanza hay que recurrir a una serie de trucos bajo la manga que nos ayuden a remontar la adversidad, y cuando en un proyecto las cosas se retrasan y todo urge lo mejor es planear qué dejar de hacer. Es por esto que uno de los mantras del sacrosanto PMBoK es planear, planear y planear. Aún en la adversidad.

Por Mentat

Decisiones estúpidas que trastornan vidas

Martes, Abril 8th, 2008

¿Y si te dijera que una mala decisión en tu proyecto puede ser cuestión de vida o muerte? Seguramente pensarías que no es para tanto, que tu proyecto sólo se trata de desarrollar algún sistema de software, editar y publicar un libro o la apertura de un nuevo centro comercial. Pero transformar una vida por una mala decisión está más cerca de lo que piensas, me explico.

Érase una vez un proyecto muy, muy lejano, donde olvidaron aplicar el triángulo de negociación (recursos, características y tiempo) y al cliente le prometieron el clásico proyecto triple B, el resultado obvio fue un proyecto con graves retrasos, los que buscaron recuperar poniendo el cuerpo antes que la mente, es decir, trabajando todas las noches e incluyendo sábados y domingos, en lugar de renegociar los términos del proyecto, ¿te suena conocido?. Al cabo de unos días todo mundo estaba cansado, ojeroso y sin ilusiones… pero orgullosos de haber recuperado mucho del retraso.

Algunas de las tareas pendientes debían realizarse en otra ciudad y a la persona que le tocó realizarlas estaba en tránsito de un lugar a otro cuando la cruda realidad de un pestañeo trastornó su vida, de milagro sobrevivió a ese grave accidente, pero desgraciadamente su vida nunca será igual. Esa noticia sacudió a todo mundo en la empresa, lo triste es que sólo hasta que la práctica de las noches eternas y los fines de semana laborables cobró una víctima, entendimos que estábamos poniendo en riesgo la vida de todos.

En ese tiempo estaba en un proyecto con una situación similar, muchos retrasos en una de las etapas más críticas, optamos por terminar con las jornadas de 7×24 y nos pusimos a pensar qué teníamos que hacer, concluimos que necesitábamos tres cosas

  •     Jornadas largas: Religiosamente iniciamos a las 8 y concluimos a las 22 horas en lugar de trabajar de sol a sol. Encontramos que gracias a esto los errores disminuyeron ya que las tareas que hacíamos en la noche generalmente estaban llenas de errores.
  •    Reuniones de pie: Al iniciar el día hacíamos una reunión de 15 minutos donde todos informaban brevemente su avance, identificando si algún riesgo se convertía en problema para aplicar el plan de contingencia.
  •    Compensaciones por las horas extra.

Esas tres sencillas medidas nos permitieron recuperar muchos de los retrasos, sin poner en riesgo a nadie.

Moraleja…

Resolver los retrasos poniendo el cuerpo antes que la mente puede tener consecuencias fatales, sinceramente espero que nunca te toque comprobarlo en tu proyecto, aún hoy la carga de la culpa es dura para las personas a cargo de ese proyecto. Ese hecho sensibilizó al director para poder negociar las compensaciones por las horas extra, pero nunca me gustó que aprendiéramos esa lección a golpes, habría preferido que fuera por convicción razonada.

Por Mentat

¿Qué vamos a trabajar con quién?

Lunes, Enero 7th, 2008

Ha iniciado ya el proceso de contratación de proveedores para algunas partes del proyecto, y aquí la gran pregunta es: “¿A quién elegir?”. Todos prometen las perlas de la virgen y afirman tener amplia experiencia y gran calidad en sus productos y/o servicios. Si no tenemos cuidado con esta selección podemos encontrarnos las clásicas historias de terror como la del proveedor que todo lo tenía terminado en 4 meses y 15 meses después aún le faltan tres para concluir, o aquel que nos dijo que su producto si cumplía con nuestras necesidades a un buen precio y después de firmar el contrato descubrimos que para el mantenimiento hay que pagar un exorbitante precio por hora.

Con la experiencia he comprobado que el inicio de una buena contratación es tener claro qué características necesitamos que tenga el producto (incluyendo el nivel de calidad), cuándo lo necesitamos y qué precio estamos dispuestos a pagar por él, y si, las tres variables omnipresentes de todo proyecto también se aplican al contratar proveedores, recordémoslas: Características, Recursos y Tiempo. Una vez teniendo claro que necesitamos del producto o servicio a contratar debemos plasmarlo en una Petición de propuesta (conocido también como Request for Proposal –RFP) este documento nos permitirá acortar el ciclo de contratación ya que ocuparemos menos tiempo resolviendo dudas de los proveedores.

Otro elemento importante es hacer una tabla que compare las variables cuantitativas: características, calidad, precio, tiempo de entrega, etc. Y también las cualitativas: confiabilidad, experiencia, servicio, referencias, etc.

Aquí está un check-list de lo mínimo indispensable para contratar un proveedor

• Incluye al menos tres proveedores
• Elabora una petición de propuesta (RFP)
• Haz una tabla comparativa de los proveedores
• Busca referencias de clientes previos
• En el contrato incluye cláusulas que te garanticen la entrega del producto o servicio

Algunos otros tips son: Lo barato casi siempre sale caro, elegir solamente por precio es una muy mala idea.

El trato que una empresa da a un cliente grande puede variar con un cliente chico, cuando tomes referencias de clientes previos toma en cuenta las de clientes con el mismo tamaño que tu empresa.

Moraleja…

Elegir proveedor es casi como elegir novi@, hazlo cuidadosamente ya que tendrás que vivir un buen tiempo con las consecuencias de tu elección. Y un último consejo, nunca, nunca te dejes llevar por las adulaciones de los proveedores.

Por Mentat

Cualquiera vende un dólar en 85 centavos (o Muerto y resucitado)

Lunes, Octubre 1st, 2007

Hace tiempo no posteaba porque el blog lo inicie con la intención de relatar la vida de un proyecto y resultó que el proyecto estuvo por un tiempo en animación suspendida, pero ya ha salido del coma. Resulta que cuando un directivo del cliente vio lo que iba costarles la solución comenzó a cuestionar el proyecto con el argumento de que era mucho dinero, alarmó a algunos directivos y detuvieron el proyecto para ver si valía la pena hacerlo, como alternativa a un gerente comercial de nuestra empresa se le ocurrió bajar el precio así nomás, con tal de vender el proyecto, pero le dije que cualquier… persona, puede vender un dólar en 85 centavos y que esa no era la solución, por lo que tuve que acelerar el análisis del retorno de inversión del proyecto para convencerlos de que más que un gasto era una oportunidad estratégica para ellos.

El directivo opositor era de los clásicos administradores que piensan que una buena administración es la que gasta lo menos posible, por lo que al presentar las oportunidades de negocio que la solución que planteamos les da, el patrocinador, con mucho sentido común, adoptó nuestros argumentos al ser evidente que el costo valía la pena por las oportunidades de negocio que representaba, con lo que demostramos ante el cliente (una vez más) que la mejor administración es la que busca cómo invertir para hacer crecer el negocio y no la que se preocupa por gastar lo menos posible. La frase con la que nos ganamos al patrocinador fue “El proyecto es una inversión de negocio, no un gasto administrativo”, este argumento sustentado por supuesto en cifras reales, lo convencieron de continuar con el proyecto.

Moraleja…

Dinero, siempre es el dinero… En todo proyecto el costo es un asunto importante y un argumento de los clientes para buscar una rebaja, la actitud más común y conformista es bajar el precio hasta que el cliente está de acuerdo, pero esto afecta la rentabilidad del proyecto y se convierte en un recurso del cliente para bajar los precios, un planteamiento que funciona con la mayor parte de las personas con sentido común es dejar de ver los proyectos como gasto y plantearlos como inversión, la frase “El proyecto es una inversión de negocio, no un gasto administrativo”, salvó al proyecto y ya es una de mis clásicas para proyectos futuros.

Por Mentat