¿Cuántos de nosotros nos hemos encontrado aterrizando en un proyecto que, a priori, ya nos dicen que está mal?
Normalmente, el cliente, el sponsor o el program manager, nos han dado un montón de probables razones, han hecho un diagnóstico previo e, inconscientemente, llegamos con muchas ideas que estamos dispuestos a aplicar con la primera excusa. De hecho esa misma mañana, en la ducha, ¡ya teníamos el proyecto reconducido y en curso!
Pues bien, comenzar con todas esas ideas puede ser un desastre si eso nos impide pensar con claridad, realizar nuestro propio diagnóstico y, desde el conocimiento, emitir opinión. Así sí podremos trazar ese plan que nos permita reconducir la situación, si es que eso resulta realmente necesario…
Ayer tuve la oportunidad de leer unas buenas reflexiones de Pawel Brodzinski sobre el parachute manager (el PM «apagafuegos», ése que llega como las fuerzas especiales a salvar una situación, ¿te suena?). Su consejo es bien claro: «al llegar, no cambies nada».
No importa cómo de fea nos hayan pintado la situación o lo urgente que se nos diga que se requiere un cambio. En un principio, el cambio debe estar ya en la gestión en sí, no en el proyecto.
Hay que ejercitar la paciencia ya que, en la mayor parte de los casos, nuestra visión irá cambiando en la misma medida en la que entramos en harina. Y, en buena parte de las situaciones, corremos el riesgo de estropearlo aún más debido a nuestra justificada falta de conocimiento sobre la situación.
Tira de los procesos de gestión de proyectos y apóyate en ellos, sigue los pasos y reúnete con el equipo hasta que, por tí mismo, sepas juzgar esa realidad. Y dime, cuando lo has hecho, ¿tu juicio coincide con las ideas preconcebidas de aquella mañana antes de llegar? A veces ocurre, pero no es la norma general.
Dejemos que Pawel Brodzinski nos lo explique algo mejor.
A Story of Parachute Manager: Don’t Change Anything
by Pawel Brodzinski on February 21, 2011
I had a spell in a company where I was hired to sort things out in technical department (development, quality assurance and project management). I went there with a head full of ready-to-apply ideas how to solve issues I’d heard about. One of the most important things I’ve learned there is you can’t find the right cure unless you know the disease very well. And you can’t learn what the disease is unless you get dirty going into the middle of the mess.
Pretty similar lesson I got from our Kanban story. I think this message is often lost between discussing a few simple Kanban rules, Kanban board etc. The message is: start with mapping what you have; don’t try to change the process on a day one. Reason is simple: get dirty going into the middle of the mess and then you’ll learn what you should really change in the first place.
I know it’s tempting to start adjusting surrounding world to the vision you have in your head. Every now and then I feel that whenever I find myself in new environment. But I learned to resist. First, the vision we have in our heads on the day one will be changing over time and it will be changing really fast, especially at the beginning. Second, the opinion we have about surrounding reality is wrong, at least most of the time.
So yes, my advice is: don’t change anything. Don’t change anything unless you see everyday proofs that it has to be changed. Don’t change anything unless keeping things as they are is a real pain in the ass. Don’t change anything unless you’re pretty sure you aren’t seriously screwing things up because of your limited knowledge.
It doesn’t mean you have to wait long until you start improving things. Just be sure you’ve got your hands dirty before you do that.
In my case you can count this as a part of a story of parachute manager since that’s exactly what I do now. However it works the same every time you join new environment, no matter whether it is a new team, new project, new customer, new company, new method or new people.
Tagged as: change in organization, problem solving, software business, work environment
Me gusta esto:
Me gusta Cargando...
Relacionado
being performant_ 