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

Los indicadores de avance del proyecto

Publicado el Febrero 27th, 2014 en Ejecución, Control, Seguimiento, Planeación, Alcance, Comunicaciones, Riesgos, General por admin

Hace poco estuve al cargo de varios Gerentes de Proyectos (PMs = Project Managers) con quienes interactuaba frecuentemente para conocer el avance de sus proyectos asignados. Al llegar con uno de los PMs le pregunté “¿cómo va el progreso en las actividades del proyecto?”, y el me platicó por veinte minutos todos los pormenores por los que había cruzado el equipo y abundó en las dificultades del proyecto, me comentó sobre las largas jornadas de trabajo de los integrantes y las peleas internas entre ellos, me habló sobre el pobre desempeño de alguno de los consultores y mucho, mucho más.

1.jpg

Al final de su explicación le volví a preguntar, “y… ¿cómo va el avance del proyecto?”.

Cuando se trata de un proyecto, siempre es necesario tener información para poder evaluar su progreso, pero debemos aprender a obtener y a comunicar la información estrictamente necesaria para lograr ese objetivo.

Después de una sonrisa, el PM me dijo “acabo de decirte como va el proyecto”, y yo le contesté “no, me acabas de platicar algunos pormenores de lo que ha ocurrido desde la última vez que reportaste avances, pero aún no sé si el proyecto va a terminar a tiempo o no, o si tenemos un desempeño del gasto del presupuesto dentro de los límites aceptables. Tampoco me has comentado la probabilidad de ocurrencia de los riesgos que has detectado ni el impacto que tendría si alguno de ellos se materializara. No me has permitido conocer el número de casos de prueba generados, ni aquellos que ya fueron ejecutados y de éstos cuáles han resultado exitosos y cuáles necesitan ser remediados.”

Después de dar seguimiento a múltiples proyectos con clientes de todas dimensiones, he concluido que necesito el mínimo de información objetiva y medible para darme una idea general del avance del proyecto. Una vez habiendo evaluado esa información, entonces sí me interesa conocer los detalles no-duros (subjetivos y desestructurados) más importantes que me permitan apoyar a mis PMs y al equipo de proyecto para que tengan un mejor desempeño y para alcanzar las metas del proyecto. Desde mi perspectiva se requiere un equilibrio entre información dura y no dura para llegar a conclusiones más completas.

Cuando terminé de hablar con mi colega le pregunté cuál era el SPI del proyecto (Schedule Performance Index = Índice de desempeño del cronograma) y recibí un silencio ensordecedor. Así que aprovechando que el siguiente lunes era festivo, llamé al PM, al Líder Técnico y al Líder de Pruebas del Proyecto a una junta a las 9:00am para discutir sobre esos temas. Para aprovechar el tiempo les pedí que trajeran la siguiente información lista para nuestra sesión de trabajo:

* Plan general del proyecto (incluyendo el cronograma).

* Número de horas totales del proyecto (Presupuesto original de horas).

* Número de horas consumidas al día de hoy (Valor actual de horas consumidas).

* Actividades del plan terminadas al 100% y la suma de las horas que representaba ese avance (Valor ganado)

2.jpg

Con esta información pude calcular los indicadores normales de valor ganado como el desvío actual del presupuesto y del calendario (Cost Variance y Schedule Variance respectivamente) y pude calcular algunos pronósticos como el número de horas totales invertidas al terminar el proyecto (EAC = Estimate At Completion) y el número de horas pendientes por trabajar (ETC = Estimate To Complete) si siguiéramos trabajando al mismo ritmo.

En ese momento, todos nos dimos cuenta que el proyecto iba retrasado en tiempo y que el equipo tenía un desempeño del 95%, es decir, que por cada hora trabajada solo el 95% de esa hora estaba siendo empleada en actividades que agregaban valor al progreso del proyecto como estaba definido originalmente.

También nos dimos cuenta de que estábamos gastando el presupuesto del proyecto más rápido de lo planeado y que al ritmo al que íbamos terminaríamos en números rojos al finalizar.

Adicionalmente el cliente nos estaba poniendo una restricción en el calendario, donde necesitaba recibir el sistema que estábamos construyendo a mas tardar en 2 meses incluyendo todos los entregables, y gracias a los indicadores que obtuvimos pudimos ver que eso no iba a ser posible si seguíamos trabajando al ritmo que llevábamos (SPI menos que 1).

Terminamos nuestra reunión interna después de 3 horas y le pregunté al PM acerca de la relación que llevábamos con el cliente a lo que el me contestó que era inmejorable, que estaba muy contento con el trabajo del equipo y que ya estaba viendo la manera de entregarnos otros requerimientos para futuros sistemas.

En mi opinión, hemos hecho del proceso una meta, siendo que la meta es el resultado del proyecto. El proceso es importante desde luego porque determina la recurrencia en proyectos con el mismo cliente (nuevos negocios), pero lo que debe recomendarnos es nuestra capacidad para dar resultados. He leído en diversos artículos que la administración de proyectos es tanto una ciencia como un arte y estoy de acuerdo con eso, el problema es que a veces tendemos mucho hacia el arte o hacia la ciencia de manera exclusiva y desequilibrada y perdemos el beneficio del extremo descuidado.

 3.jpg

En el caso del proyecto que les platico, le pedí al PM una revisión semanal de algunos de estos indicadores y le generé una plantilla en una hoja de cálculo para que el pudiera generar esta información con facilidad. El PM dedicó su creatividad y la del equipo a buscar maneras de revertir el retraso y aumentar la productividad para cumplir con la restricción de cronograma que teníamos. Tuvimos que agregar un apoyo externo para poder terminar a tiempo, lo que incrementó el presupuesto del proyecto, pero afortunadamente esto lo comunicamos con anticipación y no generó un problema con el cliente.

Soy un creyente de que las relaciones con los clientes deben cuidarse, pero también pienso que la relación es el camino y no la meta, y para alcanzar metas con calidad necesitamos medir, corregir y entregar.

La importancia de los mentores

Publicado el Junio 11th, 2013 en Inicio, Control, Planeación, Calidad, Recursos Humanos, General por admin

Por Fernando Valdez

Llevaba trabajando en una empresa apenas unos dos meses cuando recibí una llamada por teléfono. Contesté y era de Estados Unidos, era un gerente de servicio a clientes de nuestra empresa que a su vez tenía a una persona de finanzas al teléfono y juntos estaban pidiéndome el reporte financiero de un proyecto que yo estaba administrando. La verdad es que nunca había oído hablar de ese reporte y mis interlocutores extranjeros sonaban con mucha prisa por tenerlo en sus manos, ya que era momento de recabar información del proyecto para hacer los cargos correspondientes al cliente. Yo era el único Administrador de Proyectos extranjero (toda nuestra organización estaba basada en la ciudad de Dallas, Tx. y en Cleveland, Oh.) y yo no tenía a nadie a quien preguntarle acá en México. Además, como ya lo comenté, nuestro departamento apenas había sido creado hacía un par de meses fuera de Estados Unidos y nadie tenía la más mínima idea de cómo proceder ante tal petición. Los silencios incómodos empezaron a surgir y los gerentes al otro lado de la línea parecían muy inquietos y temerosos de que no existiera tal reporte, así que les dije que necesitaba 30 minutos para darles una respuesta al respecto. Ellos aceptaron e hicieron hincapié en que ese reporte debería ser enviado a la brevedad posible. Colgamos el teléfono y pensé: “¿que voy a hacer?”.

mentoring-w.jpg
Antes de mencionar cómo resolví el problema, déjenme hablarles un poco sobre nuestra organización y sobre las dos primeras semanas de trabajo en la misma.

Al ingresar a la compañía dos meses atrás, hice un viaje de dos semanas a Dallas, Tx para conocer a mis colegas Administradores de Proyectos y a mi jefe, el director de la Oficina de Proyectos (PMO - Project Management Office). Durante el viaje no solo los conocí, sino que me fueron explicados los procedimientos estándar de la oficina de proyectos, así como los documentos que deberíamos generar y el repositorio para almacenar dichos documentos a través de las diferentes etapas de los proyectos.

Al segundo día de estar en Dallas, mi jefe se acercó a mi escritorio y me presentó a un Administrador de Proyectos Sr. que además apoyaba a la PMO en diversas actividades. Mi jefe mencionó que cualquier duda que tuviera se la preguntara a él, ya que sería mi mentor, y me dijo que él me daría indicaciones durante los próximos días sobre lo que tendría que cuidar dentro de un proyecto.

En un principio esto se me hizo exagerado, porque para entonces yo llevaba alrededor de diez años administrando proyectos y contaba con mi certificación como Project Management Professional (PMP). En teoría todo lo que mi mentor me podría haber enseñado era algo que de alguna u otra forma yo ya había experimentado.

Mi mentor hizo una excelente tarea en mostrarme los detalles específicos de nuestra organización, cómo generar documentación, donde almacenarla y cómo conducir reuniones de equipo presenciales y virtuales con personal de la India y de otros estados de la unión americana, pero hasta  ese momento no habría surgido la necesidad de llenar algún reporte de carácter financiero.

Como Administradores de Proyectos en el área de desarrollo de sistemas computacionales no siempre nos vemos envueltos en la necesidad de manejar presupuestos en pesos o en dólares, sino presupuestos en horas-hombre.

Normalmente hacemos estimaciones de duración de los proyectos y mucho de lo que manejamos son las horas de esfuerzo que un empleado pone en el proyecto. Esto a su vez se traduce a pesos o a dólares ya que cada hora tiene una tarifa que depende de la experiencia y la naturaleza de las actividades a desempeñar por el empleado. Sin embargo, cuando se trata de los clientes, en última instancia todo lo manejamos en términos de una unidad monetaria y de aquí la importancia del reporte financiero del proyecto.

Ahora si, de regreso a la llamada que acababa de terminar con mis colegas de finanzas y de servicio a clientes. Levante inmediatamente el teléfono y le llamé a mi mentor, le expliqué la situación y el me dijo, “ah!, no te había explicado eso porque no era aún tiempo, pero dada la prisa que parecen tener, te voy a ayudar a generar el reporte y después te explico con calma los pasos para obtenerlo”. Mi mentor me dijo cómo hacer el reporte sin muchos detalles, pero dado que yo tenía ya experiencia, pude entender lo que estábamos haciendo para armar tal reporte.

organizaciones-inteligentes-610×250.jpg

Treinta minutos después de esto envié un correo electrónico con el reporte que me habían solicitado incluyendo información sólida sobre las finanzas del proyecto.

Con esto puedo extraer al menos tres experiencias que me han sido muy valiosas en los últimos años como Administrador de Proyectos:

1) Cada empresa tiene diferentes formas de hacer las cosas. Cuando llegues a una nueva compañía trata de entender y conocer los formatos y procedimientos que se manejan allí. Probablemente el reporte de comunicaciones o el cronograma se llamen igual de una empresa a otra, pero en cada una hay una manera diferente de hacerlo.

2) La importancia de tener una PMO y procedimientos estándares para la administración de proyectos. El reporte financiero que me pidieron ya tenía un formato específico e incluía información cuya fuente era ampliamente conocida por todos. Utilizábamos un sistema para capturar las horas dedicadas a cada proyecto en una base semanal, de tal forma que al ejecutar un procedimiento de actualización, dichos números eran cargados automáticamente al reporte financiero y el resto era hacer algunos cálculos muy sencillos, así como comentarios acerca del desempeño del proyecto.

3) La importancia de tener un mentor que apoye a los nuevos empleados o a los mentoria-w.jpgAdministradores de Proyectos Jr. El tiempo que estos mentores invierten en un miembro del equipo es invaluable y la mayormente beneficiada es la empresa, ya que se hace un uso más óptimo de los recursos en lo general.

Mis colegas de finanzas y servicio al cliente ya conocían el formato que les había enviado, así que sólo se concentraron en extraer la información y pudieron cumplir a su vez con su trabajo de manera puntual.
Espero que esta experiencia haya sido útil para ustedes. Hasta la próxima.

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

Porqué es de suma importancia contar con una PMO

Publicado el Abril 17th, 2012 en Control, Planeación, Grupos de Proceso, Alcance, Recursos Humanos por admin

diverse_business_man_and_woman_40435468.jpg

El término “dejar ir a un empleado” fue acuñado en los Estados Unidos y se refiere al acto de despedir a un empleado, pero desde el punto de vista del idioma Español, éste es un término impreciso, ya que un empleado no está solicitando permiso para retirarse y la compañía no está otorgando dicho permiso. Más bien este término es un eufemismo con el cual se da a entender al empleado que la compañía le está retirando la oportunidad laboral por el motivo que ésta considere conveniente, sin preguntarle su parecer al afectado.

Como quiera que sea, hace un par de meses “dejamos ir” a dos Project Managers de nuestra organización, presuntamente por su bajo desempeño. La misma noche que ocurrió esto, una de las afectadas publicó en su muro de Facebook que “no entendía el porqué de la decisión”. Esta situación me hizo reflexionar acerca los motivos que dieron lugar a su despido, muy al margen de opiniones subjetivas acerca de su desempeño, considerando sólo los hechos. Llegué a una conclusión basado en algunos hechos históricos que a continuación les comento.

Yo llegué a esta organización (mi trabajo actual) ocupando un puesto de Project Manager (al igual que mis dos compañeros que fueron despedidos). Mi organización consistía de un director de la PMO (Project Management Office u Oficina de Proyectos) y alrededor de diez Administradores de Proyectos técnicos (de tecnología de información). Después de dos años fui promovido a Gerente de Tecnología para el área de Monterrey, México, dado que la oficina local iba a crecer a más del doble y se requería una cabeza que administrara las operaciones locales. Un par de meses después de haber aceptado la promoción, la Oficina de Proyectos desapareció y los Administradores de Proyectos fueron movidos a diferentes áreas de la organización, principalmente al área de Servicio a Clientes, donde ahora administraban los proyectos de inicio a fin (contacto con el cliente, creación y autorización de proyectos, levantamiento de requerimientos, desarrollo del proyecto, cierre, seguimiento post-implementación, etc.), no sólo la parte técnica.

La rutina semanal durante mi trabajo como Administrador de Proyectos era más o menos la siguiente:

  • Lunes: Reunión general con el equipo para revisar avances. Cálculo de avances y entrega de reportes de avance a la Dirección de Proyectos (quien a su vez informaba a la alta gerencia).
  • Martes: Junta de planeación de recursos o Staffing meeting. En esta reunión nos juntábamos la alta gerencia, el equipo de autorización de proyectos, todos los gerentes funcionales, todos los gerentes de solución y todos los gerentes de proyectos. En esta reunión evaluábamos la participación de cada individuo (programador, arquitecto, ingeniero de calidad, administrador de proyectos, etc.) en los diferentes proyectos que habían sido autorizados, basándonos en la experiencia de cada individuo en las diferentes herramientas o áreas del negocio a atender. Por ejemplo, verificábamos si era factible tener a Juan en el proyecto X que requería de sus conocimientos técnicos. Lo mismo para Pedro, Hugo y Guillermo, basados en los mismos criterios (habilidades, conocimientos técnicos, conocimientos del área de negocio, experiencia dentro de la organización, importancia del proyecto, importancia del cliente, etc.). El resultado de esta reunión era un portafolio de proyectos con recursos tentativamente comprometidos para cada proyecto en determinada fecha. Esto nos permitía tener una versión tentativa de lo que iba a estar haciendo cada recurso de nuestro personal en el futuro cercano (es decir, los próximos dos meses).
  • Miércoles: Día normal de trabajo. Revisión de avances a nivel local (cada PM con su equipo).
  • Jueves: Reunión del Project Stearing Team (Equipo de Dirección de Proyectos). Este equipo se encargaba de elegir los proyectos a empezar y de priorizarlos de acuerdo con diferentes criterios, como eran: tamaño del proyecto, importancia del proyecto, urgencia del mismo, cliente a atender, etc. También los jueves teníamos la junta de la PMO en la que el director revisaba que nosotros, los líderes de proyectos, siguiéramos con el proceso de documentación, actualización de estadísticas y con cada paso definido en nuestro Ciclo de Vida de Desarrollo de Sistemas (SDLC por sus siglas en inglés). En esta junta teníamos oportunidad de mencionar si veíamos algún riesgo aumentando en probabilidad de ocurrir, mencionar sobre problemas sin resolver o sobre algún miembro de la organización que estuviera obstaculizando el progreso de nuestro proyecto. Si esto último era el caso, el director de la PMO tendría una reunión con la persona que estaba obstaculizando el proyecto y se avocaba a resolver el conflicto y permitir que el proyecto siguiera un curso adecuado.
  • Viernes: Revisión de avances y actualización de métricas. Aquí cada empleado capturaba las horas dedicadas a cada proyecto y a cada actividad realizada durante la semana. Además llenaban un reporte de las actividades que estaría realizando las próximas cinco semanas de acuerdo con los planes que se le habían entregado. Adicionalmente, se hacía un reporte de horas a cobrar a los clientes en el futuro cercano basados en las horas que facturaban los empleados. Todo esto nos daba mucha información que utilizaríamos para tomar decisiones para las siguientes actividades de nuestro equipo de proyecto.
  • Sábado y Domingo: Si habíamos sido exitosos en cumplir los objetivos semanales y si no había ninguna urgencia por parte del cliente, entonces podíamos descansar. En ocasiones, cuando trabajaba con personal de la India, yo iniciaba mi semana el domingo a las 9:30 de la noche, comunicándome con los miembros de mi equipo allá y dándoles dirección para el inicio de la semana, ya que para ellos eran las 9 de la mañana del lunes (iban adelantados 11.5 horas).

No quiero decir que durante el día sólo realizábamos las actividades arriba descritas. Cada día era un reto equilibrar las actividades administrativas, de personal, reportes y muchas más necesarias para el correcto funcionamiento del equipo. En ocasiones, como lo mencioné en un post anterior, era necesario ver por las necesidades de cada miembro del equipo llegando hasta el extremo de verificar si habían comido ese día o no. Eliminar obstáculos que amenazaban el avance del equipo, coordinar las comunicaciones, resolver conflictos, etc. eran actividades diarias para mí como líder de mis proyectos, agregando la complejidad que supone tener a medio equipo a 750 km de distancia y la otra parte del mismo, al otro lado del mundo.

outsourcing.jpg

 Algunos amables lectores se estarán preguntando: “¿qué tiene que ver todo esto con los dos compañeros que despidieron?” Permítanme contarles lo que ocurrió posterior a mi promoción y salida de la PMO.

Cuando el departamento de tecnología dejó de administrar los proyectos y esta administración pasó al departamento de servicio a clientes, algunos compañeros líderes de proyecto no se sintieron muy cómodos y renunciaron, lo que provocó que la organización perdiera experiencia, disciplina y estructura en la administración de proyectos y, al mismo tiempo, nos hizo vulnerables al desorden y la falta de lineamientos administrativos que la PMO brindaba a la organización. Esto no fue evidente de inmediato, sino que poco a poco ha ido revelándose como un problema que necesita solución y al que no muchos aceptan como un error de la administración general de la organización.

En un intento por regresar a “la normalidad”, el departamento de tecnología contrató dos Líderes de Proyecto (exactamente, tal como lo sospechan, contratamos a los dos líderes de proyecto que acabamos de “dejar ir”). Estos dos compañeros hicieron todo lo que pudieron: tomaron sus herramientas de administración de proyectos y planearon el alcance de sus proyectos, monitorearon su ejecución, documentaron riesgos y facilitaron la comunicación. No todas las decisiones que hicieron fueron las mejores, pero definitivamente tuvieron aciertos durante su gestión.

Desafortunadamente, dado que los recursos no les pertenecían del todo (en una organización funcional los recursos le pertenecen a un gerente funcional que los pone en préstamo para el desarrollo de los proyectos y cuando el proyecto acaba, los recursos son regresados a lo que llamamos “el pool” de recursos en espera de otro proyecto), en ocasiones les retiraban o les sustituían personal por otro menos capaz o menos apropiado para el trabajo, lo que impactaba enormemente al proyecto y, desde luego, a su reputación como líderes del proyecto.

A la vuelta de un par de años, en un recorte de gastos, los administradores de proyectos fueron puestos a disposición del mercado laboral global como ya lo mencioné al inicio de esta entrada.

¿Cuál fue la diferencia de estos dos líderes de proyectos y aquellos que formamos el primer grupo de administradores de proyectos en la organización? Mi respuesta a esta pregunta, para hacerla muy breve, es que aquellos que estábamos antes pertenecíamos a una PMO.

La Oficina de Proyectos no sólo nos daba herramientas para administrar nuestros proyectos, sino que establecía el estándar de trabajo dentro de la organización. Adicionalmente el Director de la PMO abogaba por los proyectos desde una posición jerárquica superior a la que teníamos los Gerentes de Proyectos. Y por último, las reuniones de planeación de recursos (Staffing Meeting) y la junta de la PMO, resultaron ser claves para el control del personal y para comprometer a los recursos adecuados a permanecer dentro de la fase más crítica de los proyectos.

No soy especialista en Oficinas de Proyectos, pero sí fui un usuario muy afortunado de la misma. La “protección” con la que se contaba en una PMO ofrecía la estabilidad que un Project Manager necesita para realizar su trabajo efectivamente. Los principios, las lecciones aprendidas, la metodología, los formatos, los estándares y las herramientas eran transferidos a todos los miembros del equipo de la PMO reduciendo así dificultades e incrementando las probabilidades de éxito individual de los miembros.

dynamiclifedevelopment3019.jpg Quizá en la organización a la que los apreciables lectores pertenecen, no exista una oficina de proyectos que provea dirección y facilite su gestión. Incluso quizá se haya juzgado a uno que otro buen elemento por su falta de habilidad para administrar los proyectos, pero si en una organización que maneja proyectos, los líderes de los mismos no tienen un respaldo formal y no se encuentran adecuadamente ubicado en el organigrama, es muy probable que seguirán teniendo algunos éxitos y muchos fracasos en el desempeño de sus proyectos.

Cuando un líder de proyectos le reporta a un gerente de sistemas, se convierte en un líder-de-proyectos-de-sistemas. Cuando un líder de proyectos le reporta a un gerente de operaciones, se convierte en un líder-de-proyectos-de-operaciones. Y así sucesivamente. La organización necesita líderes de proyectos con influencia en toda la organización. Un proyecto de sistemas no solamente involucrará una pieza de software, porque el software no es nada si no tiene usuarios. En un proyecto de software comúnmente se requerirá involucrar empleados de otros departamentos como mercadotecnia, servicio a clientes, operaciones, ventas, productos, calidad, etc. Un líder de proyectos debe poder dar seguimiento a todas las fases del proyecto, o como le llaman en mi organización, un enfoque end-to-end —de inicio a fin— desde la concepción hasta la operación. Cuando un proyecto se entrega, entonces se da a luz un producto y es aquí cuando ocurre el “cambio de estafeta”, de un líder de proyectos a un líder de producto que se encargará de administrar la relación con el cliente y con el equipo de operaciones que lo mantiene en funcionamiento.

Quizá como conclusión a esta reflexión, puedo decir que este es un asunto de autoridad. Si los líderes de proyecto no son investidos con la autoridad que su puesto requiere y a lo largo de toda la organización, entonces no dejarán de ser empleados de un departamento que hacen lo que el gerente de ese departamento necesita. Se perderá la visión general y será muy difícil alcanzar los objetivos globales de la compañía.

Cuando mi organización “dejó ir” a esos dos Project Managers, se deshizo de dos empleados de tecnología que, de acuerdo con la percepción general, administraban los proyectos y, a veces, los obstaculizaban. Suena injusto, ¿no es cierto?

Fernando Valdez

 

La productividad de un líder

Publicado el Febrero 29th, 2012 en Ejecución, Recursos Humanos, Comunicaciones por admin

Existe una injustificada discusión entre lo que tendría que hacer el líder del proyecto y lo que realmente está haciendo y dicha discusión tiene que ver con el nivel de involucramiento que éste debería tener con los entregables técnicos del proyecto. Para salir pronto de dudas, el líder del proyecto debería estar más involucrado con el funcionamiento del equipo, que con la fabricación de los entregables. Algunos autores dicen que un administrador de proyectos nunca debería encontrarse en la ruta crítica del proyecto y esto es porque sus actividades, de naturaleza principalmente administrativas, pueden retrasar el trabajo de los demás compañeros. Esto no quiere decir que un líder de proyectos no debería participar en la construcción de entregables de un proyecto, pero si advierte que hay diferencias entre las actividades de un miembro del equipo y su líder.

estres-laboral.jpgComo decimos en México: “ni tanto que queme al santo, ni tanto que no lo alumbre”. Como PMs necesitamos documentar, necesitamos reportar avances, necesitamos documentar riesgos y actualizar el registro de problemas, necesitamos actualizar el cronograma y volver a empezar otra vez. Sin embargo, además de todo esto, necesitamos ser productivos. Necesitamos entregar resultados. Los resultados que un PM entrega no sólo son documentos escritos, sino resultados a través del equipo del proyecto. Que se haga lo que está planeado hacerse, que se entregue lo que se prometió con el nivel de calidad que se esperaba. Que la gente haga lo que tiene que hacer.

Hace ya muchos años, cuando formaba parte de Toastmasters, una organización internacional cuyos miembros aprenden y practican técnicas de comunicación en público y de liderazgo, tuve la oportunidad de formar parte de la mesa directiva que se integraba de siete personas: un presidente, un vicepresidente educativo, un vicepresidente de membresías y otros cuatro individuos con diferentes funciones. Yo asumí la presidencia del club y en la toma de protesta, el presidente saliente me dijo unas palabras que tienen mucho sentido cuando se trata de dirigir equipos de trabajo. El presidente saliente me dijo: “este es el momento en el que vas a tener que hacer todo lo que se tenga que hacer en el club, pero a través de la gente”. Más adelante pude observar como muchos presidentes de otros clubes empezaban muy bien, pero terminaban solos, haciendo mediocremente todo el trabajo que tendrían que hacer siete personas, pero ellos solos o con uno o dos ayudantes informales. Pero una posición de liderazgo no supone que el líder tenga que hacerlo todo el solo, sino que tiene que motivar, coordinar, dirigir y administrar para que cada miembro del equipo haga lo que le corresponde.

Durante mi gestión como presidente del club usé esa frase como un termómetro de mi liderazgo: si me encontraba haciendo lo que se suponía que otros tendrían que estar haciendo, entonces no estaba siendo el líder que debería ser, e inmediatamente empezaba a buscar las deficiencias en mi desempeño. Debo confesar que muchas de las deficiencias que encontré en mpi mismo no tenían que ver tanto con mis capacidades técnicas como con mi carácter o falta del mismo.

En mi trabajo como líder de proyecto también cometí ese error. Hace como quince años trabajaba con un equipo muy pequeño en el que tenía un practicante (estudiante de la carrera de ingeniería en sistemas haciendo prácticas profesionales) desarrollando una parte del sistema que teníamos que entregar. A la una de la tarde estábamos por salir a comer cuando me anunció el practicante que no podía terminar lo que íbamos a presentar a las tres de la tarde, justo después de comer. Al mismo tiempo se acercó otro desarrollador y me dijo que tampoco podía estar listo para la presentación. Me enojé mucho y empecé a cuestionar su desempeño. Los interrogué para saber dónde estaban encontrando las mayores dificultades y una vez que encontramos el problema me avoqué a resolverlo con mis propias manos. Les dije “Parense junto a mi para que vean cómo se hacen las cosas”. Los mantuve a cada uno viendo sobre mis hombros hasta que, diez minutos antes de la presentación, terminé todo el trabajo, probamos y todo funcionó correctamente.

Me levanté y les dije “no merecen estar en la junta de presentación de avances” y acudí a la junta yo solo. Afortunadamente todo salió bien: el usuario quedó complacido y mi coraje ya había desaparecido. Esa noche estuve reflexionando. Desde luego estaba orgulloso por mi desempeño técnico porque había resuelto en tiempo récord lo que dos desarrolladores no habían podido resolver, pero no estaba tan orgulloso por mi desempeño como líder. Por alguna razón los desarrolladores no pudieron cumplir con su tarea y yo no me enfoqué en darles la confianza y la oportunidad para ventilar eso. Claro que el tiempo estaba encima y no podía sentarme a hacerle al psicólogo mientras teníamos que entregar un resultado, pero también es cierto que no había motivado a esos muchachos últimamente ni había dado la oportunidad para discutir dificultades acerca de sus asignaciones.

Ese día terminé con una sensación de vacío que estaba tratando de llenar con falsos sentimientos de orgullo acerca de mi desempeño técnico. El vacío tenía que ver con una falta de liderazgo. Entregamos a tiempo, pero la relación con mis desarrolladores quedó desgastada, los humillé y no les ayudé en lo absoluto. Creía que ellos deberían aprender con la valiente hazaña que yo había hecho, pero estaba muy equivocado. Ese día me prometí no volver a meter las manos en el trabajo de otro colaborador, sino apoyarlo hasta que se alcanzara el objetivo aun que eso tomara más tiempo. Esto me obligaría a supervisar frecuentemente, a motivar, a involucrarme auténticamente. En muchas ocasiones posteriores los muchachos se acercaban e insinuaban que necesitaban el tipo de “ayuda” que les habría dado en el pasado (hacerlos a un lado y hacer la programación yo mismo), pero siempre les ofrecía un tiempo para hacer preguntas que los ayudaran a salir del ciclo mental en el que habían caído, hasta que empezaban a encontrar ellos mismos la solución. Al acercarme más a mi equipo pude entender mejor cuáles eran sus fortalezas y cuales sus debilidades y me enfoqué a ayudarles a superarlas con anticipación.3d-women-arrow-011-300×300.jpg

En una ocasión asigné un trabajo a una practicante y al poco tiempo se acercó y me dijo que no podía hacer el trabajo. La escuché y le di algunas ideas de como podía resolverlo y se fue contenta a intentarlo. Regresó unas horas después diciendo “ya lo intenté y no se puede”. Le pregunté qué es lo que esperaba que yo hiciera y ella me dijo “pues que se lo asignes a alguien más y me des a mí algo más fácil” a lo que yo le contesté “aquí no estamos en la escuela en donde muchas veces se premia el esfuerzo, éste es el trabajo y el trabajo se hace o no se hace, aquí no hay calificaciones de siete  u ocho, aquí es diferente”. Después le di otros consejos de cómo podría resolver el problema y se retiró muy pensativa. Mas adelante regresó diciéndome que mi sugerencia no funcionó, pero que intentó otras muchas cosas hasta que lo logró. Yo revisé el producto y realmente el problema estaba resuelto. Me sentí muy satisfecho por no haberle resuelto la situación; ella entendió que yo estaba para ayudarle, no para resolverle sus problemas, entendió que ella era responsable por dar un resultado, ella entendió que se le pagaba un sueldo por los resultados que diera y no por intentarlo. Ella estaba motivada y yo me estaba convirtiendo en el líder de proyecto que creía que debía ser.

La productividad no tiene que ser vista como la cantidad de cosas que haces, sino como los resultados que provocas para la compañía. Los resultados de un líder de un proyecto deberían ser medidos en su capacidad por hacer que los demás den resultados, por el nivel de liderazgo que demuestras, por tu capacidad de hacer que los demás hagan lo correcto, en el tiempo adecuado y con la calidad que se requiere.

Desde luego que los reportes de avance son necesarios, pero el liderazgo es mucho mas que eso. A veces hay que ser psicólogo, a veces adivino y, si el equipo lo necesita, a veces hay que “arriesgarse” a ser un amigo para ellos.

Por Fernando Valdez

Planeando el año nuevo

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

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

Las diferencias de planear y ejecutar

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

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

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

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

Hago lo que me gusta

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

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

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

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

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

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

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

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

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

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

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

Por Fernando Valdez

El outsourcing en los proyectos… ¡Hay que atreverse!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Por Fernando Valdez

La importancia del inicio del proyecto

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

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

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

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

Las especificaciones

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

El pre-análisis

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

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

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

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

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

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

Comunicación

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

El verdadero inicio del proyecto

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

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

El problema

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

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

Saca la cabeza del lodo

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

El fin de la historia

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

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

Conclusión

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

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

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

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

Por Fernando Valdez

Riesgos vs Problemas

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

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

Ambiente del proyecto

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

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

Riesgos del proyecto

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

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

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

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

El problema

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

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

El intento por resolver el problema

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

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

Lecciones Aprendidas

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

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

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

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

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

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

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

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

Recomendaciones finales

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

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

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

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

Por Fernando Valdez

 
© 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.