Cualquiera vende 1 dolar en 85 cent.

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.

Documentar los Proyectos. El Alzheimer de Proyectos

¿Alguna de estas frases te es familiar?

“Hace tres meses les dije que necesitábamos X”
“¿Cómo fue posible que nadie se acordara de ese requisito?”
“No, nunca quedamos en que esa era mi responsabilidad”



Si alguna vez has sentido que tu cabeza y/o la de alguien próximo (arriba, abajo o a un lado) corren peligro por alguna de estas frases, es que en ese proyecto no se documentó lo suficiente.

Hace poco en una reunión de un proyecto con tres (si, 3) meses de retraso, escuché: “Ese coordinador de procesos de negocio ya lo había propuesto hace cuatro meses, pero nadie lo consideró importante y luego ni se acordaron de la propuesta”. Cuando llegó el momento de cortar cabezas, también le tocó a la persona que había hecho esa propuesta, a pesar de ser una persona muy competente tuvo que pagar los platos rotos y la ineptitud de sus colegas, porque no tuvo ninguna evidencia a la hora de deslindar responsabilidades.



Documentar es una de las actividades invaluables de un buen proyecto, y por documentar me refiero a plasmar toda la información posible en diagramas y/o documentos, sí, toda la información posible.

¿Qué debemos documentar?, absolutamente todo lo posible y/o importante; reuniones con minutas, procesos de negocio con diagramas, la visión del proyecto en un documento, los riesgos, el plan de control de calidad, etc. Para tener una lista más completa podemos consultar el viejo e invaluable PMBOK.

Vamos aclarando, el objetivo de documentar no es tener centenares de documentos con una prosa impecable o decenas de diagramas estéticamente perfectos, es bueno documentar siempre y cuando nos genere algún valor agregado, y esto puede ser por alguna de las siguientes razones:

- Comprender el dominio o negocio
- Evitar omisiones
- No depender de las personas
- Concertar acuerdos
- Registrar compromisos adquiridos

En los proyectos de alto riesgo es aún mucho más importante documentar, porque cuando algo falla catastróficamente y llega la hora de repartir culpas, crucificar responsables y rebanar cabezas (en suma: deslindar responsabilidades), las minutas son una excelente herramienta para descubrir mentiras e ineptos.

Moraleja…

No documentar en un proyecto, es como enrolar sólo a personas con Alzheimer, tal vez recuerden varias cosas de todos los acuerdos, procesos, hitos, reuniones, etc. Pero hay toneladas de información y decisiones que quedarán en el olvido por un momento y las recordaremos justo cuando hagan más daño (remember Murphy).

Así que no lo olviden: Más vale documentar que lamentar.

FACTORES AMBIENTALES DENTRO DE PROYECTOS

Cuando trabajaba en una compañía pequeña en la que la mayoría de las cosas eran predecibles, para mi no tenía mucho sentido el "distraer" tiempo del proyecto en pensar qué factores ambientales de la empresa podían afectar a mi proyecto.Cuando hablo de factores ambientales de la empresa, me estoy refiriendo a aquello que el PMBOK(1) describe en la página 83. Cito textualmente al PMBOK en su "definición" (para aquellos que no cuenten con una copia del PMBOK): "...se deben tener en cuenta todos y cada uno de los factores ambientales de la empresa y de los sistemas de la organización que estuvieran relacionados con el éxito del proyecto o pudieran influir sobre él de alguna manera."En la compañía en la que trabajo actualmente iniciamos un proyecto de desarrollo de software en el que el equipo inicial lo conformábamos un Solution Architect, dos Technical Architects, ocho Developers, dos QA Testers y su servidor como Project Manager (PM). Yo a mi vez reportaba los progresos de ese proyecto a un Program Manager (PgmM) dado que mi proyecto era parte de un esfuerzo mayor en la migración de nuestro sistema de e-Learning.El equipo de proyecto se encontraba distribuido en tres países: México, USA e India, en este último país tenía 3 de los desarrolladores.Por algunos motivos que describiré en futuros posts dado que me han dejado grandes lecciones aprendidas, el proyecto empezó a acercarse a su fecha de entrega y, como sucede con frecuencia, los entregables no se acercaban a estar 100% terminados. La presión por parte de los directivos de USA era grande dado que el cliente a su vez los presionaba a ellos. Finalmente se estableció una fecha de entrega para que el usuario entrara a ver el producto terminado el Lunes 4 de febrero de 2008. La semana anterior todo el equipo estuvo trabajando a marchas forzadas, cuando de pronto el sub-equipo de India dejó de reportar sus avances. Inmediatamente noté la ausencia de su reporte porque dada la distancia geográfica que separa a la India de nuestro país y dado que las fechas eran muy agresivas, yo había implementado un reporte diario de avance con nuestros compañeros de aquel país. Esa noche me conecté cerca de las 2:00am CST (tiempo del centro) (1:30pm IST (tiempo de India)) para ver si podía localizar a los compañeros de allá y justo eso hice. Fue cuando me explicaron lo que había sucedido y que después confirmé en un comunicado de Yahoo! News: El viernes 1o de febrero, un barco en el mar mediterráneo ancló tras verse amenazado por el clima y cortó uno de los cables que comunican por Internet al Medio Este con Europa afectando gran parte del ancho de banda de la India y otros países.En esta ocasión, más que dar Lecciones APrendidas ya digeridas, quiero compartir qué fue lo que hicimos para afrontar este problema y permitirles obtener sus propias Lecciones APrendidas (si las quieren compartir conmigo se los voy a agradecer mucho).
1. Comuniqué inmediatamente al PgmM y a los directivos de la compañía para que manejaran las expectativas con el cliente.2. La mejor comunicación para el pueblo Indio se daba a media noche nuestra, y dado que unicamente podían comunicarse por email, al mas puro estilo de aquel granjero que se corta el dedo cuando le muerde una serpiente antes de que el veneno recorra todo su cuerpo, solicité a los recursos de India que enviaran por email su código fuente para terminarlo con los recursos de occidente. Como el granjero, cortamos miembros que desde luego nos serían útiles mas tarde, pero también cortamos un potencial problema mayor en ese momento, de otra forma, si hubiera permitido que "el veneno" se esparciera por todo el proyecto hubieramos sufrido una inminente muerte.3. Uno de los arquitectos técnicos, quien me apoyaba manejando gran parte de las comunicaciones con el equipo de India y quien resolviera las dudas y problemas que a ese sub-equipo le surgían, fue asignado a concretar lo que los compañeros Indios dejaron inconcluso, así cerré la brecha de conocimiento que suponía el reasignar recursos del proyecto.4. El proyecto ya estaba en problemas y con tres recursos menos y fechas agresivas, opté por dejar que el desarrollo continuara únicamente con recursos occidentales (USA y México). Posteriormente los colegas Indios nos apoyaron en algunas tareas de menor impacto mismas que hicieron muy bien.5. Aunque ya contaba con un Risk Register, incluí dentro del mismo todo riesgo potencial para el proyecto y desarrollé planes de mitigación para aquellos con mayor probabilidad de ocurrir y mayor impacto.Aunque todo este asunto parece (y de hecho es) un asunto de manejo de riesgos, quiero comentar que muchas veces pasamos por alto los factores ambientales que envuelven al proyecto o a la compañía y muchos de estos factores pueden presentar problemas. En la página 83 del PMBOK(1) se describen algunos de los factores ambientales que existen, en este caso nos vimos afectados en la infraestructura que rodea a la compañía.Comparte conmigo y los demás lectores tus Lecciones APrendidas sobre este issue que ocurrió: ¿qué hubieras hecho en mi lugar? De la misma forma te invito a enviar cualquier comentario o experiencia que consideres de interés general para poder crecer más en nuestro conocimiento de Administración de Proyectos.(1) PMBOK 3ª Ed. Español Pág. 83
Publicado por Fernando Valdez B, PMP

Project Management Body of Knowledge (PMBOK®) es un término integral que describe la suma de conocimiento dentro de la profesión de gestión de proyectos. Al igual de lo que sucede con otras profesiones como leyes, medicina y contabilidad, lo medular del conocimiento está en quienes lo practican y en los académicos que lo aplican y los hacen progresar. La estructura de conocimiento completa de la gestión de proyectos incluye el estudio de probadas prácticas tradicionales que se aplican bastamente, como así mismo el conocimiento de innovadoras y avanzadas prácticas que han sido objeto de un uso más limitado, e incluye tanto material publicado como inédito.

La gestión de proyectos es una profesión emergente. El principal propósito de este documento es el de identificar y describir aquel subconjunto del PMBOK® que está generalmente aceptado. Generalmente aceptado quiere decir que el conocimiento y las prácticas descritas son aplicables a la mayoría de los proyectos la mayor de las veces, y que existe un amplio consenso acerca de su valor y utilidad. Generalmente aceptado no significa que el conocimiento y las prácticas descritas son o deben ser aplicadas en forma uniforme a todos los proyectos; el equipo de gestión de proyectos es siempre el responsable de determinar lo que es adecuado para un determinado proyecto. Este documento tiene como finalidad, además, la de proveer un léxico común dentro de la profesión y de la práctica para conversar y escribir acerca de la gestión de proyectos. La gestión de proyectos es una profesión relativamente joven y, aunque existe mucho de común en lo que se hace, hay muy poca similitud en los términos empleados. Este documento establece una referencia básica para todo aquel interesado en la profesión de gestión de proyectos. Esto incluye, pero sin limitarse a: .Ejecutivos sénior .Gerentes de gerentes de proyectos .Gerentes de proyectos y otros miembros del equipo de proyectos .Clientes de proyectos y otros usuarios de proyectos .Gerentes funcionales con empleados asignados a equipos de proyectos .Educadores dedicados a la docencia en gestión de proyectos y temas relacionados .Consultores y otros especialistas en gestión de proyectos y áreas relacionadas .Instructores que desarrollan programas educacionales en gestión de proyectos.

¿QUÉ ES UN PROYECTO?

Las organizaciones ejecutan el trabajo. El trabajo implica generalmente ya sea operaciones o proyectos, aunque los dos pueden traslaparse. Las operaciones y los proyectos tienen muchas características en común; por ejemplo, son:

.Ejecutados por personas.

.Restringidos por recursos limitados.

.Planificados, ejecutados y controlados.

A menudo, se implementan proyectos como una forma de lograr el plan estratégico de una organización. Las operaciones y los proyectos se diferencian, principalmente, en el hecho de que las operaciones son continuas y repetitivas, mientras que los proyectos son temporales y únicos. Así, es posible definir un proyecto en términos de sus características distintivas – un proyecto es una empresa temporal que se asume con el fin de crear un producto o servicio único. Temporal quiere decir que cada proyecto tiene un comienzo y un término definitivos. Único quiere decir que el producto o servicio es distintivamente diferente de todos los demás productos o servicios. Para muchas organizaciones, los proyectos son una forma de responder a aquellas solicitudes que no se pueden abordar dentro de los límites operacionales normales de la organización.

Los proyectos se llevan a cabo a todo nivel de la organización.Estos pueden involucrar a una sola persona o bien a varios miles de individuos. Su duración va de unas cuantas semanas a más de cinco años. Los proyectos pueden involucrar a una sola unidad de una organización o bien pueden traspasar las fronteras organizacionales, en la forma de sociedades contractuales (joint ventures) y sociedades. Los proyectos son críticos para el cumplimiento de la estrategia de negocios de la organización que los ejecuta, debido a que los proyectos son una forma de implementar la estrategia. Entre los ejemplos de proyectos se cuentan: .Desarrollo de un nuevo producto o servicio .Realización de un cambio en la estructura, dotación o estilo de una organización .Diseño de un nuevo vehículo de transporte .Desarrollo o adquisición de un sistema de información nuevo o modificado .Construcción de un edificio o de una planta .Construcción de un sistema de agua potable para una comunidad de un país en vías de desarrollo..Realización de una campaña para un fin político. .Implementación de un nuevo procedimiento o proceso.

¿EN QUÉ CONSISTE LA GESTIÓN DE PROYECTOS?

La gestión de proyectos es la aplicación del conocimiento, habilidades, herramientas y técnicas a las actividades del proyecto de forma tal de cumplir con los requerimientos del proyecto. La gestión de proyectos se lleva a cabo mediante el uso de procesos tales como: iniciación, planificación, ejecución, control y término. El equipo del proyecto gestiona el trabajo de los proyectos, trabajo que comúnmente implica: Distintas demandas de: alcance, tiempo, costo, riesgo y calidad. Clientes con diferentes necesidades y expectativas. Requerimientos identificados. Es importante hacer notar que muchos de los procesos contenidos dentro de la gestión de proyectos son iterativos por naturaleza. Esto se debe, en parte, a la existencia de y a la necesidad de una elaboración progresiva de un proyecto durante toda su ciclo de vida; es decir, mientras más sabe usted acerca de su proyecto, mejor será su capacidad para manejarlo. El término gestión de proyectos se utiliza a veces para describir un enfoque organizacional para el manejo o administración de operaciones continuas. Este enfoque, más correctamente llamado gestión por proyectos, trata los diversos aspectos de las operaciones continuas como proyectos de forma tal de aplicar a estos las técnicas de gestión de proyectos. Aunque contar con una comprensión de la gestión de proyectos es un aspecto crítico para aquella organización que realiza la gestión por proyectos, no está dentro del alcance de este documento referirse detalladamente al enfoque en sí. La Estructura de la Gerencia de Proyectos La estructura de la Gestión de Proyectos, establece una estructura básica para la comprensión de la gestión de proyectos. El Contexto de la Gestión de Proyectos, describe el ambiente en que operan los proyectos. El equipo de gestión de proyectos debe entender este contexto más amplio –la gestión de las actividades diarias del proyecto es algo necesario para el éxito, pero no suficiente. Los Procesos de la Gestión de Proyectos, describe una visión generalizada de cómo interactúan comúnmente los distintos procesos de la gestión de proyectos.

Las Áreas de Conocimiento de la Gestión de Proyectos

las Áreas de Conocimiento de la Gestión de Proyectos, describe el conocimiento y la práctica de la gestión de proyectos en términos de sus procesos integrados. Estos procesos se han organizado en nueve áreas de conocimiento, como se describe más abajo y se ilustran en la Figura 1-1.

Gestión de Integración de Proyectos, describe los procesos requeridos para asegurar que se coordinen adecuadamente los distintos elementos del proyecto. Esta consiste en el desarrollo de un plan de proyecto, la ejecución del plan de proyecto y en el control integrado de cambios. Gestión del Alcance del Proyecto, describe los procesos requeridos para asegurar que el proyecto incluya todo el trabajo requerido, y sólo el trabajo requerido, a fin de completar el proyecto exitosamente. Esta consiste en la iniciación, planificación del alcance, definición del alcance, verificación del alcance y control de cambios en el alcance.

Gestión de Duración (Tiempo) del Proyecto, describe los procesos requeridos para asegurar el término a tiempo del proyecto. Esta consiste en la definición de las actividades, la secuencia de las actividades, estimación de la duración de las actividades, desarrollo del programa y control del programa.

Gestión de Costos del Proyecto, describe los procesos requeridos para asegurar la ejecución total del proyecto dentro del presupuesto aprobado. Esta consiste en la planificación de los recursos, estimación de los costos, preparación de presupuestos de costos y control de costos. Gestión de Calidad del Proyecto, describe los procesos requeridos para asegurarse de que el proyecto satisfará las necesidades para las cuales fue ejecutado. Esta consiste en la planificación de la calidad, aseguramiento de la calidad y control de calidad.

Gestión de Recursos Humanos del Proyecto, describe los procesos requeridos para realizar un uso más eficiente y eficaz de las personas involucradas con el proyecto. Esta consiste en la planificación organizacional, la adquisición de personal, y en el desarrollo del equipo. Gestión de Comunicaciones del Proyecto, describe los procesos requeridos para asegurar la generación, recopilación, diseminación, almacenamiento y disposición final de la información del proyecto en forma adecuada y a tiempo. Esta consiste en la planificación de las comunicaciones, distribución de la información, reporte del rendimiento / desempeño y cierre administrativo.

Gestión de Riesgos del Proyecto, describe los procesos que tienen que ver con la identificación, análisis y respuesta al riesgo del proyecto. Esta consiste en la planificación de la gestión de riesgos, identificación de los riesgos, análisis cualitativo de los riesgos, análisis cuantitativo de los riesgos, planificación de las respuestas a los riesgos, y monitoreo y control de los riesgos.

Gestión de Abastecimiento de Proyectos, describe los procesos requeridos para adquirir bienes y servicios desde fuera de la organización ejecutante. Esta consiste en la planificación de la adquisición, planificación del requerimiento, requisición, selección de la fuente, administración del contrato y término del contrato.

RELACIÓN CON OTRAS DISCIPLINAS DE GESTIÓN