En las últimas semanas he venido participando en varios proyectos en los cuales mis clientes son los IT Managers, y en sus discusiones he identificado un patrón muy interesante.
Casi simultáneamente, tuve una fuerte discusión con mi jefe, porque yo soy un iluso que creo que hay proyectos IT que se pueden acabar a tiempo… Oops!
No me gusta discutir, ni me gusta rogar: me encanta demostrar mediante la acción.
En estas últimas 6 semanas he podido dirigir y ejecutar (nunca he podido alejarme de mi costado técnico) proyectos para una capital en Suiza, otros 2 para Nesxxx, y arranco otro para un banco privado dentro
de poco, además de trabajar con los comerciales de la empresa para crear una nueva oferta para el mercado. En este blog hemos ilustrado cómo gestionar el tiempo (para entender como lo logramos), así que me dedicaré solamente a la dimensión de realización de proyectos:
- En el primer caso, es una iniciativa para todos los empleados de Lausana, con una plataforma para la gestión de tiempos: pude lograr terminar la primera fase en 31 días, con 30 días de avance sobre la fecha prevista. Además, hemos construído todas los aceleradores que nos permitirán de avanzar en forma ágil en el futuro, y el plan de comunicación ha creado una excelente acogida.
- En el segundo caso, un viejo proyecto de la más grande multinacional suiza, y que tiene un retardo crónico de 24 meses, será terminado en menos de 10 semanas. Esto ha permitido revivir la segunda fase del proyecto, los módulos de BI, a la cual ya se había renunciado debido a la imposibilidad de terminar los primeros 4 bloques arquitectónicos.
- Estamos construyendo una propuesta para la Arquitectura de Empresa (EA) y, particularmente, en la Gestión de Procesos de Negocio (BPM).
El caso de la discusión con mi jefe, muestra que es difícil cambiar las costumbres, así que ya no lucho contra ellas. Cuando estas en Europa Central, es difícil mostrar tus capacidades de líder: en tu tierra se habla español –idioma considerado como “del sur“–, se supone que la metodología no es tu fuerte, y que eres del tipo seguidor más que lider.
Yo no lo veo así: durante mis años jóvenes y viejos, he tenido grandes ejemplos de lo bueno y sobre todo de lo malo, y he construido mi base de conocimientos. No soy brillante, sino solamente consciente de la efemeridad de los momentos de intercambio: es ya todo un logro poder cruzar algunas personas excepcionales. Debemos aprovecharlos mientras duran.
Así que viendo la sorpresa creada con mi intervención, decidí compartir algunas perlas con mis colegas y con mi jefe, que ahora presento aquí:
Hipótesis de arranque: El peso específico proviene no de dónde vienes ni de lo que creen de tí, sino de lo serio de tu propuesta para gerenciar el proyecto. No dejes instalar un ambiente sumamente tecnocrático, incluso si tu proyecto es exclusivamente técnico. Los proyectos son dirigidos y ejecutados por individuos. Ellos son el corazón y la sustancia misma, la razón de ser de los proyectos, los artistas que realizarán la obra.
Primero, muestre interés y respeto por su cliente. Nunca se debe hacer un proyecto con alguien con quien no se tiene un contacto orgánico, excepto si la distancia lo justifica. Dele la mano, obsérvelo, establezca sus valores y su experiencia, examine lo que él espera del proyecto. Sea auténtico: tiene que gustarle aproximarse a las personas.
Segundo, deje sus vicios en casa. Yo era super-tímido, y no era capaz de hablar a mi madre, literalmente. Los años, la experiencia y sobre todo la necesidad me han mostrado que no es algo para reflexionar: su timidez puede interpretarse como antipatía, y si la cosa comienza así, puede hacer una cruz sobre su proyecto.
Tercero, establezca solidos canales de comunicación: las tarjetas corporativas y los primeros correos electrónicos son la clave. Nuevamente, hágalo en forma espontánea. Yo casi nunca lo hago en la primera reunión, sobre todo porque una persona importante faltará a esa reunión. Haga un comentario adecuado, y proceda a pasar su tarjeta, sin esperar las de los demás. Un clima de colaboración se puede establecer solamente si no parece tieso (stiff) y que sigue un guión.
Cuarto: hable de la importancia de la comunicación. Desde el principio muestre que conoce su dossier. Normalmente me invitan a última hora, pero ya he establecido una táctica para este tipo de casos: siéntese y observe. Luego responda.
Cuando conozca muy bien el caso del cliente, entonces es más fácil pero toca asumir otra táctica: siéntese y observe. Luego responda.
Alinearse con el cliente solamente es posible cuando usted ha entendido lo que él busca. Escuche lo que dice. No lo suponga. Busque que exprese lo que no dice voluntariamente.
La gente solamente va a comunicar si usted le da el espacio. No falta el jefe de proyecto que parece profeta… y se quedará en el desierto. Deje hablar a los comerciales, que para eso les pagan. No tema corregirlos (a los comerciales), y no tema detenerlos para que no invadan el espacio del cliente.
Quinto, el principio esencial: recuerde que en cada momento en que Ud. se presenta delante de un interlocutor, usted vende confianza. Sea consciente que en la comunicación hay varios actores, y que los demás esperan algo de Usted. No les haga perder el tiempo, porque perderá su confianza y hasta su paciencia. No diga muy poco porque lo verán como alguien vacío y falto de resultados concretos.
Sé que soy un jefe de proyecto muy estricto, pero no soy pedante. Dónde esta la diferencia? Creo que mi éxito viene de confiar en los colaboradores, en respetar su arte, y en pensar que son adultos e inteligentes. Entonces –y sobre todo para ver la reacción de los nuevos miembros– solicito explícitamente lo siguiente: No espero que lo intenten [resolver el problema] , espero positivamente que lo hagan [proponer soluciones y resolver el problema].
No es un juego: esto es un negocio, y usted es la/el responsable.
Sexto: láncese al agua antes que sus colaboradores, y nade en el problema con el cliente. Muestre el ejemplo, y sus ingenieros lo acompañarán, al menos los buenos. Entienda su cliente: no lo juzgue! esto es un formidable error de apreciación.
Sea siempre competente en los dominios en los cuales realiza proyectos, conozca sus asociados de negocios (las empresas que proveen la tecnología y los productos que Uds. llevan a sus clientes), no dependa en canales intermedios (porque los problemas siempre recaerán en Ud. durante la fase más crítica del proyecto). En ningún caso tenga miedo de doblarse las mangas de la camisa!
Séptimo: construya una plataforma de comunicación. Ella debe ser heterogénea, y jerárquica, agradable y práctica. No installe simplemente un bugzilla (porque muestra que espera muchos problemas), ni inunde de correos (otra fuente de e-mails == Ud. será percibido como un problema más, no como una solución).
Facilite el intercambio. No pierda tiempo y no lo haga perder a los demás. Presente su propuesta a su cliente rápidamente, y construya un prototipo a alta velocidad. No olvide adaptarlo a la imagen del cliente, a su proyecto.
Octavo, entienda que las expectativas de un proyecto IT casi nunca son técnicas. Aunque no lo crea, eso casi nunca sucede. El IT obtenido es una oportunidad, una solución. Es esa la razón del foso entre los actores del negocio y los actores IT en la misma empresa. En otras palabras: lo único que cuenta es cómo se soportan los servicios del negocio de su cliente con los productos obtenidos del proyecto que Ud. dirige. Durante mis años de experiencia con grandes grupos y pequeñas empresas, siempre he visto este fenómeno, lo que me llevó a hacer un doctorado en este dominio.
Creo que estas perlas contienen muchos elementos para hacer la diferencia entre el éxito y el fracaso de un proyecto IT. No se extrañe si mientras usted ejecuta su proyecto, la gente termina por adoptar algo que funcione rápidamente y no lo espere. Tal eventualidad puede pasar a pesar de que Ud. entregue su solución de acuerdo con el plan
Si hay deseo, hay una forma de lograrlo.
Mantenga la lucidez
Proponga soluciones, no explique los problemas
No Comments Yet