Debo confesar que estoy disfrutando como nunca de mi giro profesional hacia la formación. El día a día es una experiencia positiva en la cual no dejo de aprender de la interacción con los alumnos. Pero hay días difíciles, sobretodo cuando recibes comentarios negativos del tipo:

• Esto siempre se ha hecho de esta forma, ahora no lo vamos a cambiar.
• Lo habitual en el sector en el cual trabajo no es lo que nos comentas.
• Pero en mi empresa lo hacemos de otra forma.

Me pareció realmente muy curiosa esta falta de flexibilidad y resistencia al cambio, precisamente viniendo de los alumnos. Querer aprender es estar abierto a nuevos puntos de vista. Cuando más intentaba ayudarles a salir de su área de confort, más resistencia me encontraba, demasiado acomodados en su situación actual

Y luego me acordé de un post que leí recientemente llamado “Stockholm Syndrome in change management” de Jack Vinson. En el comenta que Carol Murchie está utilizando el término de Síndrome de Estocolmo para hablar de los cambios en negocios y tecnología, explotando la analogía entre usuarios unidos a sus captores para resistir el cambio tecnológico. Lo describe como:

Síndrome de Estocolmo: personas que están atrapadas en el uso de herramientas y procesos de bajo rendimiento, pero que no quieren renunciar a ellas.

Justo lo que me he estado encontrando con mis alumnos en clase. Profundizando más en la idea Carol Murchie comenta que el Síndrome de Estocolmo se agudiza en aquellos que se quejan sobre un proceso pero que en el momento que se les ofrece una posible solución, acaban comentando que el método actual realmente no es tan malo para evitar el cambio.

El post de Jack Vinson finaliza dando alguna pista de cómo vencer esta resistencia al del cambio:

• Ponerse en su piel: verlo desde su propia perspectiva.
• Hablarles en su propio idioma.

Con el objetivo que el cambio se debe entender y que para esto es necesario que se vea que va a satisfacer mejor sus necesidades.

La próxima vez que me encuentre con situaciones similares, no sólo con mis alumnos, tendré presente esta definición de Síndrome de Estocolmo. Y a ver si logro conseguir ayudar a vencer la resistencia al cambio.

Si queréis ver el post de Jack Vinson lo encontraréis en: http://blog.jackvinson.com

Fotografía de Jordi Soldevila.

En post del pasado 21 de marzo “Errores al construir la WBS”, se comentaba el informe de Josh Nankivel “Top 7 WBS Mistakes Project Managers Make”. El tercer error descrito “Organizar la WBS según las fases del proyecto”, ha creado cierta controversia.

Varios lectores han expresado su opinión en el blog pidiendo que se ahonde más en el tema, mis alumnos se han divido entre los que están de acuerdo, los que creen que es un error y los que todavía se han confundido más. Como resumen me he convertido en “la chica WBS”, a quien todo el mundo en clase le pregunta cómo desarrollar la WBS y para qué sirve realmente.

¿Por qué ha creado tanta controversia considerar un error organizar la WBS por fases del proyecto? Pues porque según el PMBOK^® la WBS puede crearse usando las fases del ciclo de vida del proyecto como primer nivel de descomposición, por lo tanto lo que Josh Nankivel considera un error es correcto según el estándar del PMI. Y además es una práctica habitual en muchos sectores.

Personalmente también opino que es un error, y os describo mis motivos:

#1: La WBS debe basarse en una estructura por entregables y no temporal.

Las fases son períodos temporales, por lo tanto si iniciamos la WBS por fases será difícil no continuar con esta tendencia temporal en el desglose de los siguientes niveles, olvidando que la estructura de la WBS debe ser por entregables. Organizándola por fases no llevará a un esquema mental de secuencia de actividades y no de entregables.

#2: La WBS debe distinguirse claramente del Cronograma

Aunque el objetivo de la WBS va más allá de que sea el punto de partida del cronograma, muchas veces nos centramos solamente en éste cuando estamos creando la WBS. Lo cual a crear una WBS pensada en el Cronograma y a que no sea posible distinguir claramente entre la WBS y el Cronograma.

#3: La WBS debe cumplir la regla del 100%

La regla del 100% no sólo nos dice que la WBS debe incluir la totalidad del alcance del proyecto, sino que va más allá. Según el “Practice Standard for Work Breakdown Structures Second Edition” la regla del 100% debe cumplirse en todos los niveles. En una WBS organizada por fases va a ser difícil cumplir con esta regla, seguro que habrá más de un entregable que pertenece a más de una fase de nuestro proyecto. Si es así nos será imposible cumplir con la regla del 100%.

#4: La WBS es el marco de control del proyecto

El objetivo de la WBS es definir todo el trabajo del proyecto con diversos propósitos: aclarar el alcance del proyecto, es el punto de partida de otros procesos . . . y sobretodo establecer un marco de control del proyecto. Nuestra WBS sólo debería cambiar ante un cambio de alcance y no con el cambio temporal de una funcionalidad de una fase a otra.

Como resumen lo que más me atrajo del informe no fue la clasificación de errores, sino que su descripción es una buena reflexión sobre cuáles son los objetivos y propósitos de la WBS.

Os animo pues a seguir con esta controversia; que expreséis vuestra opinión sobre los  motivos expuestos y si creéis que falta alguno.

Autor de la imagen: Alex Lomix