Anécdotas varias sobre Gestión de Proyectos.

La importancia d el inicio del proyecto *

Posted on Julio 14th, 2011 in Inicio, Alcance, Comunicaciones by admin

Yo 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 qué 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. Aun 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 aun 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.
¿Qué vamos a hacer y por qué es importante? *
Publicado el Agosto 16th, 2007 en General por admin

Es un hecho, esto de administrar un proyecto puede consumir todo tu tiempo, claro, si te

dejas. Estos últimos días estuve involucrado en comprender qué es lo que quiere el
cliente, pero termine por entender que lo verdaderamente vital es saber por qué es
importante el proyecto para su empresa. En el intervalo entre uno y otro también me di
cuenta que si no planeo bien mi tiempo pasare más tiempo en el zoológico del proyecto
que con mi familia.

Bueno, manos a las teclas, para entender qué hacía el cliente comencé por hacer la
agenda de reuniones con todos los involucrados y enviarles la convocatoria para las
reuniones, una semana interrogándolos y otra digiriendo toda la información de las 40
hojas de minutas.

Planear las reuniones nos dio una mejor respuesta de los gerentes y mandos medios, que
por cierto contestaron con diferentes enfoques cuando les pregunte qué necesitaban. Los
gerentes tienen una muy buena idea de cómo debe funcionar todo, pero los mandos
medios saben que la realidad es otra, si me hubiera quedado con la perspectiva de los
gerentes seguro que una vez terminado el proyecto los mandos medios y usuarios finales
nunca hubieran usado el sistema porque no contemplaba esos pequeños grandes cambios
que la práctica optimiza a partir de la teoría. Lo bueno es que eso lo aprendí de la forma
ruda hace dos proyectos.

Para unificar criterios me sirvió mucho modelar el proceso de negocio de la empresa, ya

sobre los diagramas se limaron asperezas entre directivos y mandos medios, llegando
todos a un acuerdo de por qué era importante el proyecto y qué necesitaban que hiciera
el sistema para ayudarles a automatizar su proceso de negocio. Muchas de las
divergencias eran detalles que se fueron minimizando al preguntarles como niño de dos
años por qué hacían esto en lugar de aquello, eso los llevó a razonar qué era lo
verdaderamente importante en el negocio en lugar de perderse en detalles burocráticos.
Moraleja…

Hay que entender qué es lo que vamos a hacer y aún más importante, por qué lo estamos
haciendo. Si no sabemos el valor real que genera el proyecto para el negocio corremos el
riesgo de hacer un sistema que termine sin ser usado. Entender el “Qué” nos da una vista
detallada del árbol, pero saber el “Por qué” nos da la perspectiva del bosque.

Por Mentat
En su s marcas, listos… Reunión de arranque! *
Publicado el Julio 13th, 2007 en General por admin

Por fin nos conocimos todos los stakeholders del proyecto, todos firmaron el acta
constitutiva y formalmente, nació el proyecto. La astrologa oficial del equipo, una de las
clientas principales, lo designó bajo el signo de cáncer y si no la detiene el patrocinador,
capaz que le hace su carta astral.

El único detalle fuera de lo planeado fue la insistencia del cliente del área de operaciones,
en aparecer como responsable de todas y cada una de las revisiones, fue un momento
tenso, cuando no quería ceder y pensaba que todas las revisiones las debería aprobar él,
hasta que le comenté que si estaba dispuesto a revisar todas y cada una de las hojas del
documento de especificación de requerimientos, que por lo menos sería de 200 hojas, no
habría problema por mi parte, siempre y cuando el patrocinador del proyecto no lo
objetara. Bajo esa hábil persuasión, el síndrome del gallo del corral lo abandonó y aceptó
sólo supervisar los requerimientos correspondientes a su área.

Moraleja…

En todo equipo de trabajo, puedes encontrarte a una o varias personas que sufren el
síndrome del gallo del corral, esto es, quieren que todos los reconozcan como los líderes
natos y los que tienen la última palabra y saben todo, contadísimas son las ocasiones
donde esto último es cierto, pero en la mayoría de los casos son personas con complejo
de inferioridad, o temor a perder su puesto, o simplemente unos patanes dictatoriales, así
que si tienes más de un gallo en el corral, prepara un plan de contención.

Por Mentat