Te recomiendo no leer este post si antes no has leído la Parte 1, 2 y 3.

Los siguientes pasos son donde El Jefe de proyecto demuestra realmente que existe y no es un Fantasma.

8. Gestionar el presupuesto y control de esfuerzo.

Trabajas con personas, no con maquinas, ni esclavos, si piensas que el día necesita mas horas es porque algo haces mal invirtiendo tu esfuerzo en algo que no deberías. No se puede robar tiempo al reloj pero si se puede aprovechar bien ese tiempo.

Como jefe de proyecto debes ayudar a avanzar, no solo controlar a tu equipo, sin que te lo digan debes saber cuando algo se atora, se estanca. Destrabar esos nudos ayudan a mantener el ritmo pero sobre todo a no perder tiempo. Esa excusa de – no lo sabia – se soluciona con la aplicación del punto 2.

Cuando tu equipo es realmente un proveedor debes informarle mas que a un equipo interno, ya que al estar fuera tiende a desentenderse de lo que le pasa a u cliente ya que tiene mas y depende de tu feedback, ayudarle en que sus pagos lleguen a tiempo ademas de ser consiente de que al ser un proveedor y no ser empleado o socio su compromiso es variable según el tiempo que disponga para cada proyecto. Prevée que debes consultar su disponibilidad y mantén una comunicación fluía antes de plantear la presentación de una propuesta a un cliente.

Tanto el Equipo como el Proveedor deben validar la propuesta de proyecto o podrás caer en el juego de – no tengo presupuesto y dame lo que puedas con esto que te doy – eso no es una solución, es un problema que crea ofertas mediocres.

Gestiona el tiempo sobre el presupuesto, analiza la fecha de inicio, fecha de entrega para revisión y fecha de lanzamiento. Si ves que le das poco tiempo a tu proveedor y ajustas el coste sólo por tener mas margen cuenta que muchas cosas fallarán, es mejor rechazar un proyecto que ajustar el tiempo al mínimo para conseguirlo. Esto puede cambiar si puedes hacer que el equipo propio o del proveedor pueda crecer en función de la demanda.

Otro tema importante es es el control de las «horas extras», así como decíamos que el infierno se construyo con pequeños detalles, al equipo o proveedor le puedes agotar con esos pequeños detalles. Si se aplica bien el punto 4. se trazarían límites de tiempo, fechas o inversión sobre cada pieza del proyecto. Aquí el Jefe de Proyecto debe ser quien maneje bien al cliente, hacerle ver y entender el porque se puede invertir o no mas tiempo, sobre todo dejando claro si es una nueva funcionalidad, un pequeño cambio que puede hacerlo el propio cliente o un bug.

9. Aprende a transferir la información.

Personalmente he sufrido que te cambien de jefe de proyecto varias veces dentro del mismo proyecto, incluso que te cambien de Ejecutivo de Cuentas, eso es lo peor para un cliente ya que se siente perdido al no saber en manos de quien está. Si has creado un metodo punto 3. todo debería estar escrito, a tu remplazo enseñarle como gestionaste el proyecto y transfiere todos los puntos críticos. Tampoco tienes que dejar una biblia pero no le sueltes a una persona nueva sin siquiera darle los emails de las personas involucradas en el proyecto.

Para un Jefe de Proyecto no debe existir la palabra «Secreto», todo debería ser público y accesible,  el equipo no debe esconder cosas por vergüenza o peor por miedo a la crítica, si trabajas con personas profesionales y maduras sabrán encajar una crítica o reprimenda, además de que eso ayudará a nunca mas volver a cometer el mismo error. Sentimentalismos fuera!

Si por el contrario trabajas con Proveedores analiza su situación, se le deben facturas, le falta información, necesita mas tiempo, esos detalles que hacen que el proveedor funcione perfectamente están en lo que le ayuda a trabajar, no en palmaditas en la espalda.

Contabilidad, a veces los Jefes de Proyectos manejan una cuenta de gastos, tanto personales como del equipo, eso es sagrado para la empresa, pide ayuda si no se te da bien, pero sobre todo no te olvides de hacerlo o tu remplazo se encontrará con un problema que va mas allá del proyecto.

10. El verdadero team building.

La motivación debe estar estrechamente relacionada al éxito en el método de trabajo, mas no sujeta a la consecución de tareas o hitos. ¿Porqué? pues porque de nada sirve invitar a pizzas, ir al karting o hacer un paintball si el día a día es un suplicio sin soluciones reales y solo presión.
Un equipo se crea trabajando, ayudando a que cada día se sienta el avance, se solucionen problemas y se obtengan respuestas.
La motivación debería estar en dar las herramientas necesarias para hacer confortable el trabajo del equipo, y no me refiero a una silla o un monitor, sino al apoyo en la gestión y la respuesta inmediata a dudas o requerimientos.

Todas estas conclusiones son parte de mi propia experiencia, fallos y dolores de cabeza como consultor, jefe de proyecto, product manager, miembro de varios equipos pero sobre todo de mi etapa actual como proveedor de desarrollo, es como me gustaría trabajar con una agencia o con un proveedor, como personalmente quisiera evitar perder dinero por simple vagancia de las personas en no leer o seguir un método.

Pienso que los Jefes de Proyecto son necesarios cuando las personas involucradas son de mas de dos o varias empresas, pero deben ser útiles y dejar de ser el perfil «florero», lindo pero inútil y con corta vida sin ningún poder. Al Jefe de Proyecto hay que darle poder o será un pañuelo de lagrimas de usar y tirar.

Espero que le sirva de ayuda a cualquiera que empiece el camino como Jefe de Proyecto o este trabajando con alguno que necesita un poco de ayuda ;)

Ser útil es dar soluciones y no mandar a arreglar a otra persona el problema.

Próximamente... "El Consultor Sabelotodo" o mejor dicho, que debería saber y hacer un consultor.

Si empiezas por este post te recomiendo leer antes el la Parte 1 y Parte 2. Donde describimos al Jefe de Proyecto Fantasma y luego damos los primeros pasos en la planificación de un proyecto.

Los siguientes pasos se aplican mas durante la vida y evolución del proyecto:

5. Anticiparse usando la experiencia y un poco de intuición.

Las dudas en un proyecto son normales, es mas seria raro no tenerlas, pero lo que no se puede hacer es obviarlas o asumir algo sin estar seguro, para ello mejor ver el punto 2.
Si el punto 2. no te aclara nada usa la experiencia propia o del equipo, aunque cada proyecto es diferente comparten muchas cosas, sobre todo si el proyecto es del mismo tipo.

Por ejemplo, si estas gestionando una revista sabes que de entrada necesitas saber el formato del archivo de edición, indesign o quarkxpress, el peso y formato de las imágenes y tener todas las fuentes. Si llevas una campaña pues necesitas conocer el presupuesto, el plan de medios y la estrategia de marketing, para el caso de los proyectos web es importante tener los accesos al gestor del dominio, al servidor y saber donde terminara hosteada la web contando ademas con el tiempo que tomara la migración de los datos o los Correos.

El que asume destruye.

En los proyectos que incluyen programación existen los Bugs, estos son pequeños errores o incoherencias que se crean al programar, hasta el día de hoy no he conocido un programador que no tenga ningún bug, pero si están los que lo localizan rápido para solucionarlo y están también los que entierran el bulto para que no se note. Aquí el Jefe de Proyecto debe saber que pasa, aplicar el punto 2. una y otra vez, sobre todo para poder explicar al cliente porque ese bug y como se puede solucionar.

6. Traer orden al caos y ser hábil con las crisis.

No importa el tamaño del proyecto todos tienen sus crisis, estas se producen por la propia desorganización de las personas, el punto 3. es la mejor forma de dominar o encausar ese caos, si practicas la máxima de

Lo que no esta escrito no existe

Evitaras reuniones insufribles, solo reúnete para hacer un seguimiento de tareas, revisar el avance o encontrar una solución, ponle limite al tiempo de la reunión y ten claro los puntos a debatir trazando un objetivo al finalizar esa reunión, si dura mas de 30 minutos es mejor sintetizar para avanzar y terminar que alargarla por el mero hecho de seguir hablando, las actas de reunión son tediosas, lo mejor es usar el mismo sistema GTD, Emails o Trac para plasmar las próximas tareas o cerrar las pendientes.

7. Educa al cliente y no subestimes su ignorancia.

Algo típico es – el cliente no se entera – o – da igual no se dará cuenta – si un Jefe de Proyecto dice eso espera lo peor, el asumir que el cliente es tonto y que le da igual el dinero que esta pagando por un producto o servicio es típico de un Jefe de Proyecto mediocre e incompetente, será el primero en lavarse las manos si algo sale mal ya que Asumió que el cliente no se dará cuenta del fallo, error o ver lo incompleto.
En todos los proyectos que he trabajado el cliente siempre se da cuenta de todo pero a su manera, sin saber realmente la razón, esto le crea tal malestar que pensara que le están engañando.

En el caso de los proyectos web la mayoría de los clientes no quieren oír las palabras como, Post Type, Loop, Javascript, Editor, Subir archivo, Version, Core y demas palabrejas. Es verdad que el cliente no debe saber exactamente como programaste una animación con canvas y js, pero si debes explicarle como funciona, sus capacidades pero sobre todo sus limites, no debes enseñarle a programar pero debes educarle a oír y leer lo que se le envía.

El cliente debe entender que es su web su proyecto, a menos que pague un servicio de actualización, lo que debe entender es que cuando terminas el proyecto él y solo él será quien lo mantendrá y alimentará.
Dentro del organigrama de una empresa siempre habrá un responsable con el cual el Jefe de Proyecto tendrá mayor contacto y es a esa persona la que se debe enseñar todo, bien y claro, los mínimos detalles, personalmente suelo incluir al cliente en el método de gestión e información del propio proyecto, lo malo es que si el cliente no se convierte en parte proyecto será un lastre, debe ser consciente de que debe aprender, entender y practicar el punto 2. Si toma esa postura será mas fácil resolver los problemas o de plantear soluciones sin sobrepasar el presupuesto. Si no toma esa postura considera no volver a trabajar con ese cliente.

El lunes el último post…

En el post anterior conocimos a nuestro personaje y planteamos las siguientes preguntas:

Esto es evitable? si.
Depende solo del Jefe de Proyecto? no.
El Jefe de Proyecto es el único culpable? no.
Puede hacer algo el equipo? si.
Debe cambiar el papel del cliente? si.
Los proveedores pueden hacerlo algo? si.

¿Que debe hacer realmente un jefe de proyecto?

Los primeros pasos en el nacimiento de un plan de proyecto serían:

1. La evolución del Brief.

El brief es ese documento o email con las lineas e ideas base de todo proyecto, puede ser tan corto como 3 lineas o ser un documento de varias paginas, lo importante es saber que no esta escrito en piedra.

Durante el avance del proyecto puede que ese brief inicial ya no tenga mucho sentido, pero se debe respetar su esencia.

El brief debe plantear, las necesidades del cliente, lo que realmente el cliente necesita, lo que el equipo puede ofrecer con lo que sabe y tiene, pero sobre todo plantear un reto hacia donde debería ir el equipo. De esta manera todos saben hacia donde van, como y con que herramientas se cuentan ademas de que se necesitaría para conseguir el objetivo. Sintetizar esto es un arte, toma tiempo pero vale la pena. Ademas si se promete algo al equipo hay que cumplirlo, no prometas una ayuda que jamas llegara por el simple hecho de «motivar».

2.Preguntar, Preguntar y Preguntar al equipo y al cliente.

Hasta saber todos los detalles de un proyecto incluso cosas que en teoría no debería saber, razones o técnicas de programación, dificultades técnicas, funcionamiento técnico, lenguajes y frameworks utilizados.

En este punto el equipo debe y tiene que explicarlo todo lo mejor posible con el objetivo de informar al Jefe de proyecto de todo lo necesario para que pueda informar al cliente correctamente. Lo peor que puede hacer un miembro del equipo o el propio Jefe de Proyecto es decir – Eso no tengo porque saberlo – o – no es mi/su problema -.
En la reunión inicial siempre digo que

La peor pregunta es la que no se dice.

3. Crear un método o técnica de comunicación.

Por lo general a la gente le cuesta aprender procesos nuevos, pero hay que explicar, respetar y usar ese método hasta el cansancio. Si trabajas con muchos perfiles distintos hay que llevarlos a todos por el mismo camino y con el mismo lenguaje, crear un glosario de términos puede ayudar, pero sobre todo no dejar que nadie se desvíe del método, si usas un sistema de gestión de tareas, GTD, como daylight, wunderlist o teambox, profundizar en su funcionamiento hasta llegar el nivel de poder explicar al equipo como debe usarlo, ahora si aprender a usar la herramienta de gestión genera muchos pasos innecesarios es mejor seguir buscando un método adecuado ya que cada equipo y cada proyecto tiene su propia actitud.

Por ejemplo, en un equipo de desarrollo de software donde todos, incluido el jefe de proyecto lee código los suyo es usar un trac sobre un repositorio, así todo esta enlazado en el mismo. En otros casos donde los miembros del equipo tienen una tarea y capacidades distintas los suyo es encontrar un punto medio, si el trabajo esta mas en gestionar tareas individuales pues un GTD multi usuario vendría mucho mejor.
Personalmente no soy partidario de usar el email como gestor de tareas ya que no creo que sea una herramienta adecuada para ello, a menos que el proyecto dependa mas de comunicación que de la gestión de archivos, datos y tareas.
Aunque se escoja esa herramienta en consenso con el equipo, la decisión final debe estar en el Jefe de Proyecto y escogiendo la que mas fácil le sea manejar.

En ocasiones el Jefe de Proyecto se ve empujado a usar varias herramientas para diferentes niveles de comunicación, una para la gestión con proveedores, para la gestión del equipo y recursos, para la gestión de información con los diferentes niveles de la empresa y otra para comunicarse con el cliente. No recomiendo esto ya que por razones obvias puede llevar al caos pero si no puedes centralizar todo utiliza una sola de ellas para llevar el seguimiento de las otras o recurre al infalible papel y lápiz.

Si implantas una herramienta respetarla y has que la respeten.

4. Plantea objetivos realistas y a corto plazo.

La razón es muy sencilla, no poner una meta eterna o tan lejana que sea casi inalcanzable, con objetivos a corto plazo hay mayor satisfacción en el equipo ya que esa lista de tareas se va reduciendo conforme avanzas, si las tareas duran mas de una semana transformarlo en un objetivo. Jamas propongas metas por el mero hecho de satisfacer al cliente, es mejor decir la verdad que hacer la pelota y luego fallar incumpliendo una fecha.

Si usas el método SCRUM usar objetivos a corto plazo ayuda, aunque tampoco te salva.

Los objetivos tampoco tienen porqué estar relacionados sólo con el proyecto, pueden plantearse objetivos de conocimiento del equipo para ganar ya sea experiencia en algo nuevo o motivar con un reto al que todo el equipo quiera llegar. Como por ejemplo: Aprender un nuevo lenguaje, Conocer mejor un tipo de servicio o producto, Desarrollar una nueva tecnología o metodología interna.

Continua…

Este es el primero de 4 posts sobre el mundo de la gestión de proyectos.

Desde hace varios años trabajo como proveedor de desarrollo y consultoría web para agencias de publicidad, comunicación, marketing y diseño. El resto de «tipos» de agencias son simplemente lo mismo con otro nombre. Y en todas ellas hay una «persona» que le llaman El Jefe de Proyecto según el cache de la agencia le llaman El Project Manager o simplemente «El Project».

Pero antes de escribir esta entrada hice una búsqueda en google, de algunos resultados, seleccione estos posts con títulos interesantes ej:

– Cuatro cualidades que debe tener un buen jefe de proyecto.
– El Jefe de Proyecto.
– Cinco cualidades deseables para ser un bine jefe de proyecto.
– 14 maneras de ser el peor jefe de proyecto.

El autor de este ultimo seguro llego al mismo punto que yo, el soberano cansancio de lidiar con «Fantasmas», uso esta palabra de manera literal, no como sinónimo de «Farsante» ya que el que actúa como farsante sabe incluso mentir bien, en el caso del «Jefe de proyecto fantasma» es el que aparece solo cuando hay que exigir explicaciones o al final del proyecto para decir que hay que darse prisa para cumplir las fechas. Porque durante todo el proyecto esta persona no existe, responde emails tarde y sin sentido, pregunta miles de veces lo mismo y a veces se va de vacaciones en medio del proyecto. También seria el «Jefe de Proyectos Itinerante» que es el que la agencia crea por no escoger bien a la persona encargada, empiezan a rotar personas hasta que de pronto dejan al proyecto sin su Jefe porque de tanto actor se acaban los papeles.

Pero ¿Como es este ser?, antes un poco de historia.
En los inicios de las agencias existían los vendedores, por lo general eran los propios dueños de las agencias, que sabían todo el manejo del negocio, pasaron por todos los niveles hasta convertirse en el dueño de su «producto» y lo que vendían era a si mismos y la agencia era un reflejo de él.
Cuando las agencias crecieron y el jefe ya con la pasta suficiente para dedicarse a dar charlas y compartir su conocimiento (muchas veces se agradece) empiezan a buscar Vendedores a Sueldo y Comisión, el perfil de este nuevo empleado era vender, vender lo que sea y como sea con tal de conseguir sus comisiones o primas, muy efectivo a la hora de hacer dinero y poco problemático cuando hay poca demanda.
Conforme las agencias crecieron y aglutinaron servicios de varios profesionales el Vendedor de toda la vida conforme aprende el negocio sube escalones hasta llegar a llamarse Director de Marketing, con este nuevo puesto su trabajo se transforma en lobby por lo que llevar un cliente o un proyecto en concreto se convierte en un «desafío» como ya tiene a su cargo varios clientes, necesita gente a su cargo y contrata «gente» para que hagan su trabajo naciendo así los «Ejecutivos de Cuentas» el cliente mas el producto pasan a llamarse Cuentas, ya no importa ni lo que la agencia ofrece ni el producto solo generar dinero y manejar una cuenta de ingresos (los gastos son problema de contabilidad).
Y así llegamos al nacimiento del Jefe de Proyectos, una figura secuestrada de los entornos de desarrollo de software o ingeniería he importada a las Agencias y que mejor idea que hacer que un Ejecutivo de Cuentas o Key Account Manager sea el Jefe de proyecto. Es en este preciso momento donde todo se vuelve negro. Así como nace el Jefe de proyecto nacen también los Product Managers (a mi pesar fui uno), los New-media Managers, Bussines Managers y además seudo posiciones capaz de crear mas problemas que soluciones a que lo único que tienen es responsabilidades pero nada de apoyo por parte de sus superiores. Los consultores mejor ponerlos aparte, trataré mi experiencia en consultoras y consultor independiente en otro post.

El mayor problema de estos perfiles es su falta de experiencia, poco interés y sobre todo su ego. Creen que preguntar algo que no saben es quedar en ridículo, mantener un control sobre una tarea es algo muy complejo y tienen una adicción al ASAP. A ojos del cliente pretenden saberlo todo dándole siempre la razón o hechandole la culpa al «equipo» un equipo que depende de él. Incluso pretenden usar herramientas de control como basecamp, projects, omniplanner para simular que lo tienen todo planificado, para luego olvidarse de ellas.

Su arma de destrucción masiva es el CC o CCO del email, cuando alguien debe tomar una decisión para avanzar en el proyecto o solucionar algún tema crean una cadena de mails metiendo en copia hasta a personas que jamas participaron en el proyecto, generando conversaciones absurdas llenas de pajas mentales sin aporte alguno, la detonación de esa bomba llega cuando alguien de la cadena de emails mete en la copia al «JEFE» esperando que sea él quien tome una decisión sin siquiera saber la evolución, eso se llama comúnmente «tirar el muerto» a lo que el jefaso responde con – Convoco una reunión urgente – lo peor es que en esa reunión es totalmente improductiva ya que lo único que se hace es ver cual es el macho alfa y empezar a echar culpas.

Una vez que la bomba estalla el siguiente paso es… nada!… algo que no entiendo porque pasa pero de pronto esa cadena de emails se para, reina la calma y el silencio, en ese momento el equipo visto que nadie decide ni concluye nada insiste y a los días se determina una solución que ya se tomo hace días pero no se validó y es ahí donde alguien del equipo para avanzar toma la decisión de continuar con tal de no parar y llegar a tiempo a la fecha de entrega. Una fecha de entrega que por lo general el Jefe de Proyecto desconoce, incluso desconoce el procedimiento de entrega.

El resultado de la típica gestión de un Project Manager es el agobio y cansancio del equipo, genera un malestar emocional con la frase lapidaria – vamos a acabarlo Ya! para cobrar -, es en ese momento cuando se generan errores y se dan cuenta a última hora de los «pequeños detalles» (con detallitos se construyo el infierno), detalles olvidados durante la evolución del proyecto. Ademas de las necesidades de ultima hora del cliente hay que sumarle las correcciones obvias que tiene todo proyecto, todo esto traducido en horas y horas de desvío que conllevan una perdida del porcentaje de beneficio sobre el proyecto.

Esto es evitable? si.
Depende solo del Jefe de Proyecto? no.
El Jefe de Proyecto es el único culpable? no.
Puede hacer algo el equipo? si.
Debe cambiar el papel del cliente? si.
Los proveedores pueden hacer algo? si.

¿Que debe hacer realmente un jefe de proyecto?

Continua…