La semana pasada coincidí con un excompañero de trabajo que es project manager en una consultora internacional. Después de ponernos al día sobre lo que estábamos haciendo, le pregunté sobre la crisis y sobre cómo estaba afectando a su trabajo.
Después de sonreír, su respuesta fue:
“Me faltan cerdos en mis proyectos”
Ante tal respuesta me quedé con cara de jugador de póker ya que no sabía exactamente a que se estaba refiriendo. Al ver mi reacción, me dijo rápidamente que acababa de hacer un curso de métodos ágiles de desarrollo de productos y que se refería a los roles de gallina y cerdo que suele utilizar SCRUM para representar diferentes niveles de implicación del personal.
Esta separación entre gallinas y cerdos la oí yo por primera vez hace muchos años, durante la puesta en marcha de un sistema de calidad. Se utilizaba como símil para diferenciar entre lo que significa estar implicado y estar involucrado, para ello utilizaba los roles que tienen una gallina y un cerdo a la hora de confeccionar unos huevos con beicon. En este plato la gallina está implicada ya que pone huevos, pero el cerdo está involucrado, su compromiso es mucho mayor, ya que se sacrifica para su confección.
En SCRUM se suele diferenciar entre los roles cerdo (product owner, scrum master y equipo de desarrollo) y los roles gallina (clientes, usuarios y managers) para poner de manifiesto los diferentes niveles de compromiso con el proyecto.
Pues bien, mi excompañero me explicó que la queja de que faltan cerdos en sus proyectos venía por el cambio de actitud que había observado en muchas personas a raíz de la crisis. Al parecer había aumentado la aversión al riesgo y el miedo a fracasar lo que provoca un compromiso menor con muchas iniciativas nuevas y muchos proyectos. Esto le estaba suponiendo un problema ya que le costaba mucho más conseguir la implicación de los miembros de su equipo en el proyecto.
Delante de una crisis yo hubiera esperado un aumento del compromiso pero parece ser que no es así.
¿Habéis notado algo parecido?
Cierto. Desde funcionarios en las administraciones a dependientes de supermercados. Desde conductores de autobús a gerentes de inmobiliarias. ¡El que se mueva no sale en la foto!
Gracias por tu respuesta Albert. Estoy de acuerdo respecto a que los PMs deberían estar integrados y no un ente aparte. Respecto al nivel de conocimiento, es un tema que discutimos en el Master, y que creo que se indicó que debe haber una base de conocimiento operativo. Indicas que no debe ser el experto y estamos totalmente de acuerdo, pero en mi compañía muchos no tienen apenas idea y es precisamente por este motivo que se concentran en las tareas administrativas y en cumplir hitos. Les cuesta horrores aportar a la gestión de riesgos, recursos, prioridades, etc. porque no entienden y no tienen criterio para discernir lo que les puedan decir los expertos. ¿Qué ocurre si dentro del equipo hay discrepancias entre dos expertos? Sin un conocimiento mínimo, ¿cómo puede el PM hacer de árbitro? Poniendo un ejemplo un poco extremo si quieres, yo, aun habiendo cursado el MPM no creo que pudiera gestionar un proyecto de construcción de viviendas o una fábrica de pollos. No creo que consiguiera llevarlo al éxito por mucha metodología de proyectos que aplicara. No me entedáis mal, el debate que quería lanzar es fruto de convivir con PMs “demasiado PMs”, centrados en metodología y alejados de operativa, y bajo mi punto de vista esto quema a los potenciales “cerdos”. Lo hablamos en un futuro post!
Gracias Rubén por tu interesante y valiente comentario. Comentas varios temas que merecen todo un post, intento responderte. En principio no debería de haber un “el otro lado”, siempre he pensado que los proyectos han de ser de la organización más que de un departamento o de otro. Como tampoco los PM deberían solo hacer tareas administrativas, han de conseguir que las cosas funcionen. Esto último no se consigue exigiendo, si no facilitando el trabajo al equipo y distribuyendo los roles y responsabilidades. Respecto a las preguntas sobre la involucración y el conocimiento en la parte operativa, te diría que depende de lo que entiendas por la parte operativa. Como base el PM no es el experto, los expertos están en tu equipo y por tanto el PM no puede entrar en el campo “técnico”, tiene que confiar en los expertos, en sus estimaciones y en lo que proponen. Donde sí que tiene que entrar es en identificar los riesgos y los problemas que existen en la parte operativa, conflictos, falta de recursos, prioridades no claras,…. y gestionarlos como tal. Lo dicho, una respuesta detallada necesitaría todo un post, intentaré que sea el próximo.
Buenas a todos de nuevo. Me gustaría dar mi visión desde “el otro lado”. En estos momentos soy yo o gente de mis equipos que de un modo u otro son incluidos en proyectos (nuevos procesos, productos, etc.). Para que los participantes del proyecto puedan involucrarse, deben poder hacerlo. La crisis, afecta más si cabe, a los departamentos operativos, y el headcount está en el lindar o algo por debajo de lo que la carga de trabajo requiere, por lo que, si no están claramente definidos los tiempos que debe dedicar al proyecto, es evidente que no van a poder con todo. Por norma general, se van a dedicar a contentar al jefe más que al proyecto externo (por la cuenta que le trae…).
Otro punto interesante que estoy viendo recientemente, es ver como el PM se dedica principalmente a tomar notas, actualizar el Gantt y pasar el acta de la reunión, dejando casi todas las decisiones y aportación de ideas al equipo. El PM parece ajeno “al trabajo” y se dedica más a la parte formal y a EXIGIR deadlines e hitos sin “importarle” demasiado si al final está haciendóse lo correcto o no.
Evidentemente podemos zanjar la discusión si me decís que el problema es que son malos PMs (y estos lo son) o la empresa debe asignar mas recursos, pero ¿qué hay respecto a la involucración de los PMs en las partes más operativas? ¿Hasta dónde debe llegar el conocimiento de un PM en los temas operativos relacionados con el Proyecto? Un abrazo!
Yo necesito un porquerizo que me quiera…
Quien quiera cerdos en su proyecto, debe alimentarlos para que actúen como tal.
Me explico: yo siempre he intentado ser un “cerdo” en mi trabajo, y me gusta trabajar con “cerdos”. Pero con el inicio de la crisis se han desarrollado dos actitudes: la comentada de no “arriesgar”, la gente intenta cumplir, pero evitar el fracaso… eso es contrario a una “cerda” actitud.
Pero es importante recalcar la otra actitud: mi mesa está llena de CV’s de “cerdos”, dispuestos a ensuciarse lo necesario.
Con esta “amenaza” que seguro que muchos reconocen, obtienes el efecto contrario: la gente quizás trabaje más, pero se implicara menos, y eso, cuando tengas un momento crítico y mires a tu alrededor, te darás cuenta que estás solo.
Por lo que, si quieres un cerdo en tu vida, paga por él.
Yo también hace más de un año que lo noto y creo que es debido a un doble sentimiento, por un lado el miedo a perder el trabajo con lo que se prefiere ser mediocre a fracasar y por otro la sensación de que las empresas tampoco se involucran. Aquí los managers, project y demás, deben hacer su trabajo de lograr involucrar a su equipo pero también de protegerlo.
Esto va también relacionado con el comentario reiterativo de Albert respecto a arriesgrase. Hay que lograr que el equipo pierda el miedo al riesgo, sino llega a ser temerario, pero hay que apoyarlo y lo dicho, protegerlo.
Gracias Manuel y Albert por vuestros comentarios
Gracias Manuel por el comentario. Pues en todos mis post intento fomentar precisamente lo contrario, arriesgarse y perder el miedo al fracaso. Es el único camino posible que veo para cambiar y lanzar iniciativas nuevas.
Por mi parte, sí lo noté, pero no es nada reciente: ya en 2009 empezó mucha gente a mi alrededor la política de “recoger velas” o la de “aparentar ser una piedra”. O sea, no hacer ruido, no moverse demasiado y, desde luego, no involucrarse en nada de lo que pudiera salir escaldado.
Será el fruto, quizá, de una sociedad cainita en la que siempre habrá alguien esperando a que otro cometa un error para señalarle con el dedo como el culpable de todo.