Sistemática-mente: la importancia de ceñirse al guión

Cuando el otro día extraía 13 ideas sobre Scrum que puedes aplicar en tu gestión, hubo una que se me quedó dando vueltas. En concreto, la de “Respeta los procesos y las herramientas, aunque parezca aburrido

Podemos hablar de Scrum. O de GTD. O de cómo gestionar una reunión. O de cómo hacer un brainstorming. O como gestionar tu información. O de un proceso de gestión comercial, o de calidad total. O de una rutina de entrenamiento. O de una dieta de adelgazamiento. O de una fórmula para ordenar tus armarios. Da lo mismo. Hay decenas de situaciones para las que se han definido “fórmulas” para guiar la acción y que, si se siguen adecuadamente, dan resultados.

“Si se siguen adecuadamente”. Y ahí está el quid de la cuestión.

Muchas veces nos encelamos en buscar “la herramienta perfecta”, o “el proceso perfecto”. Aquella que sí, de una vez, nos permita obtener los resultados que queremos. Y lo que suele pasar es que las herramientas, las instrucciones, ya existen; quizás no perfectas, pero sin duda más que suficientes. Pero no seguimos las instrucciones, no nos ceñimos al guión. Quizás sí al principio, pero rápidamente nos desenganchamos: porque nos aburrimos, porque “lo damos por sabido”, porque “bueno, esto no es tan importante y me lo puedo saltar”, porque “esto lo voy a hacer a mi manera”, porque “a mí me gusta ser más flexible”. Pedimos herramientas pero, cuando las tenemos, no las usamos como debemos, nos dejamos ir. La cabra tira al monte, y pasados un tiempo volvemos a estar donde estábamos. Y entonces le echamos la culpa a la herramienta, “es que no funciona”, y vuelta a empezar. Algo perfecto para los fabricantes de métodos y herramientas, que te venderán la enésima regurgitación de lo mismo (“eh, pero ahora sí, éste sí que es el método definitivo y revolucionario”). Pero el problema no está ahí. La mayoría de los problemas, y de sus soluciones, tienen las letras gordas. Solo hay que seguir las instrucciones.

No sé hasta qué punto estoy proyectando aquí mi forma de ser (porque sí, éste es uno de mis talones de Aquiles), pero lo cierto es que cuando miro alrededor creo que es algo bastante generalizado.

Y me atrevería a decir que es un importante factor de éxito, que está al alcance de cualquiera. Cíñete al puñetero guión. Elige la metodología, el proceso, la herramienta… que te de la gana, y luego cíñete a lo que has elegido. Hazlo el tiempo suficiente, y con el rigor necesario, como para poder valorar si funciona o no. Consolida. Y luego, si tienes que refinar, refina. Si puedes adaptar, adapta. Pero para entonces seguro que ya estás varios pasos más cerca de lo que querías conseguir, y desde luego mucho más cerca que si vives a base de improvisación e impulsos.

Contenido relacionado:

Continue Reading

Trece ideas de Scrum que puedes aplicar en tu gestión

Scrum por allí, Scrum por allá… llevo oyendo hablar de Scrum mucho tiempo ya, “una metodología de desarrollo de software”, “tiene que ver con el mundo de agile”, “cosas de techies”. En definitiva, oyendo campanas pero sin haber dedicado nunca tiempo a profundizar lo suficiente.

Bueno, ahora ya sé de dónde vienen las campanas :) He puesto foco durante unas horas a entender mejor que es eso de Scrum (gracias a este curso online, y a leer la guía oficial de Scrum), y cómo funciona. Efectivamente, Scrum es una metodología de desarrollo de producto (normalmente vinculado al mundo del software) que se enmarca dentro de la filosofía Agile. Diría (y aquí si algún experto me tiene que corregir que lo haga) que es una forma (¿la que más éxito ha tenido?) de “aterrizar” la filosofía del manifiesto ágil en algo más concreto y funcional.

Ahora bien, es evidente que Scrum tiene su origen y su “caldo de cultivo” en el mundo del desarrollo del software, y se ve claramente que muchas de las cosa que plantea es ahí donde tienen todo el sentido del mundo, y donde los expertos lo explotan mayoritariamente. Lo que me iba cuestionando a medida que leía era: ¿es aplicable Scrum a otros ámbitos, a la gestión de proyectos menos técnicos? Algo me dice que sí, que la dinámica de trabajo puede ser extrapolada (con más o menos “ajustes”).

Fruto de esa reflexión, y más allá de que se pueda aplicar la metodología de forma más o menos estricta, he extraído estas trece ideas de Scrum que se pueden aplicar a la gestión de cualquier proyecto:

  • Ten siempre el valor aportado al cliente como vara de medir: En Scrum, los elementos del product backlog se priorizan en función del valor que van a aportar al cliente. Lo que más valor aporte, se busca hacer cuanto antes mejor. El objetivo que persigue el “producto incremental” siempre es buscar aportar el mayor valor posible, cuanto más tangible mejor. La definición de requerimientos, el feedback en las revisiones… siempre está orientado a lo mismo. Esta “obsesión por el valor” es algo que no debe perderse de vista nunca en el desarrollo de un proyecto. ¿Cuántas veces, en el fragor de la batalla, nos miramos demasiado el ombligo y nos olvidamos de para qué estamos trabajando, nos enredamos en discusiones bizantinas que no llevan a ningún sitio, o nos emocionamos con detalles que apenas le aportan a nadie? Pues eso, no perdamos la brújula de la aportación de valor.
  • Organiza tus proyectos como sucesión de miniproyectos cerrados: se definen los “sprints” como periodos de una a cuatro semanas de trabajo sobre una serie de elementos del backlog (elementos que se definen al principio del sprint y que no se tocan) que, al finalizar, dan como resultado una “versión funcional del producto”. Este enfoque elimina la incertidumbre, los cambios de prioridades, el pasarse la vida replanteándose cosas… y permite al equipo centrarse en “producir” sin interferencias del exterior durante el sprint. Nos centramos en lo que hemos definido para el sprint, nos aislamos del exterior (la relación con el exterior es cosa del product owner) y sacamos el producto que nos habíamos propuesto sacar. Lo que haya que cambiar, lo que haya que corregir, las nuevas prioridades… ya se abordarán en el siguiente sprint (que, como llegará pronto, en ningún caso nos va a suponer un gran problema).
  • Entrega producto valioso desde el primer momento: además de funcionar como una sucesión de “miniproyectos”, en los sprints el objetivo es que al terminarlo haya un resultado final. Con cada “miniproyecto” el resultado será mejor y mejor (iteraciones), pero desde el primer momento se busca resolución y no hay que esperar a que transcurran n meses para tener algo tangible o darse cuenta de que, oh, no has ido por el buen camino. De hecho, idealmente, podrías abandonar el proyecto al terminar cualquier “sprint” y el resultado sería valioso por sí mismo. De esta forma, todo el trabajo que haces tiene sentido y aporta valor por sí mismo.
  • Feedback, feedback y más feedback: igual que en el caso del design thinking, el objetivo es que tras cada “sprint” se produzca una revisión que permita validar que efectivamente el resultado incremental aumenta el valor, ver lo que funciona y lo que no, y a partir de ahí tomar decisiones para la siguiente ronda. Este ciclo permanente de “producto funcional” y “feedback” permite ir avanzando y adaptándose de forma continua. No olvidemos exponernos al veredicto de los usuarios, no tengamos miedo a recibir sus opiniones: es lo único que nos sirve para mantener el rumbo.
  • Las prioridades las define uno y nadie más: el product owner es la figura encargada de interactuar con los “usuarios/clientes” (stakeholders en general), de identificar sus necesidades, de llegar a compromisos con ellos respecto a sus prioridades… y una vez filtrado todo ello, de trasladarselo al equipo de forma unívoca. Es el único que lo hace, la bisagra que une y a la vez aísla a los stakeholders y al equipo, el único interlocutor válido. Esta figura recupera el principio clásico de la “unicidad de mando”, y evita que haya más gente “metiendo la cuchara” y mareando al equipo, cambiando prioridades y tratando de arrimar el ascua a su sardina.
  • Protege al equipo: el equipo debe centrarse en trabajar, y aislarse en la medida de lo posible de interferencias e incertidumbres. Esto es labor del product owner, que centraliza las relaciones del equipo con los stakeholders (evitando que éstos vuelvan loco al equipo) y cerrando el alcance de los sprints en las reuniones de planificación (proporcionando un escenario de estabilidad al equipo, mientras él absorbe nuevos requisitos, cambios en prioridades, etc… que retendrá hasta llegar al siguiente sprint).
  • Comunicación multidireccional constante: Scrum define en la metodología todas las ocasiones en las que se producen interacciones entre los miembros del equipo. Reuniones de planificación, reuniones de refinamiento, reuniones diarias, reuniones de revisión, retrospectivas. En todos los casos el objetivo es “poner encima de la mesa” las distintas visiones que se puedan tener (sobre dificultades, enfoques, cómo se va a trabajar) y llegar a acuerdos. Coordinación sobre la base de la comunicación permanente.
  • Deja que los que saben se organicen: el product owner es el que define las prioridades, pero a partir de ahí es el equipo de desarrollo el que determina cómo abordar esas prioridades, qué tareas realizar, cómo repartírselas, cómo coordinar sus distintas habilidades. Son los que mejor saben hacer las cosas, y no tiene sentido que venga nadie de fuera a organizarles el trabajo. La autonomía es una clave de la motivación, y la motivación es una de las claves de un trabajo bien hecho.
  • Los equipos necesitan estar equilibrados: el equipo Scrum debe reunir, entre todos sus miembros, todas las capacidades necesarias para resolver las tareas que tiene asignadas. Es decir, no debe depender de nadie externo para avanzar. De esta forma, está 100% en las manos del equipo ejecutar lo que decidan, y no se deben quedar parados esperando a que alguien les resuelva nada. Esta visión suele ser difícil de organizar en los proyectos (y más si pensamos en proyectos transversales, con gente “de distintos departamentos” con “distintos directores”), pero resulta fundamental si queremos que las cosas salgan adelante de forma ágil.
  • Presta atención a cómo trabajas, y corrige si es necesario: las reuniones de retrospectiva se centran, al finalizar cada “sprint”, en analizar el funcionamiento del propio equipo, de identificar qué cosas han ido bien y qué cosas tienen que ir mejor. Este foco tendemos a olvidarlo y más si va a ser fuente de conflictos; para darnos palmaditas todos valemos, pero exponer problemas a la cara de forma constructiva y aceptar nuestras equivocaciones ya nos resulta más difícil. Y sin embargo es fundamental si no queremos que los problemas se enquisten.
  • Respeta los procesos y las herramientas, aunque parezca aburrido : siguiendo con la idea de la autoconciencia, la figura del Scrum Master se encarga de asegurar que el proceso se siga “a rajatabla”, que se celebren las reuniones que se tienen que celebrar y se hagan de la forma adecuada. En los proyectos todo son buenas intenciones, pero es fácil dejarnos llevar por las urgencias, por la rutina, por el “esto ya nos lo sabemos” y el “bueno, esto me lo salto que tampoco pasa nada” y a la que nos descuidamos hemos descarrilado por completo, hemos dejado de aplicar las rutinas y los hábitos que nos habíamos prometido seguir y acabamos en el batiburrillo habitual.
  • No te olvides, trabajas con personas: otra de las labores del Scrum Master es “prestar atención a las personas”. Es decir, vigilar las dinámicas interpersonales dentro del equipo, e intervenir cuando sea necesario para reconducirlo. Esta labor pone de manifiesto algo que ya he comentado en alguna ocasión: somos personas trabajando con personas, es absurdo pretender que nos relacionemos como si fuesen máquinas. Hay filias, hay fobias, hay roces, hay momentos altos y momentos bajos… y tener a una persona cuya responsabilidad es precisamente estar atento a todo eso implica reconocer esa realidad.
  • Cuanta más información tenga el equipo, mejores decisiones podrá tomar: todo el proceso de Scrum se basa en la idea de que todo es compartido por todos. Todos ven el product backlog, todos definen el sprint backlog, todos ven el seguimiento diario, todos hacen las reuniones de revisión y de retrospectiva, todos dan su opinión respecto a cómo ejecutar el trabajo… No hay carpetas privadas, no hay “ángulos ciegos”, todo el mundo tiene toda la información necesaria para hacer su trabajo. Y así, normalmente, las cosas salen mejor.

 

Contenido relacionado:

Continue Reading

Cinco reflexiones (y una confesión) sobre design thinking

Design Thinking
Design Thinking

Design Thinking es una disciplina puesta en el mapa hace no demasiados años, principalmente por la escuela de diseño de la Universidad de Stanford y la consultora IDEO. En realidad, como tantas otras veces, no es más que un destilado de muchas otras ideas que se fueron desarrollando a lo largo de los años (nada realmente nuevo bajo el sol); pero que hizo fortuna a la hora de “paquetizarlo” y transformarse en una “metodología de moda”, con la consiguiente cascada de libros, cursos, herramientas y demás. A estas alturas levantas una piedra, y te sale algo de “design thinking” seguro.

Como ya sabréis los que me leáis con más frecuencia, soy bastante alérgico a las metodologías “registradas” (en general me parecen una forma ruin de sacarte el dinero con lo que viene a ser sentido común disfrazado de gráficos y nombres cuquis y aparentemente novedosos y diferenciadores). Me interesan mucho más los principios subyacentes, ese “sentido común” que está detrás de todo. Y reconozco que detrás del “design thinking” hay bastante de eso.

Éstas son las cinco cosas que me llaman la atención del design thinking:

  • Que está centrado en el usuario. Emparenta, en este sentido, con la filosofía LEAN. Lo importante es el cliente, el usuario. Es él quien define el valor, es él quien tiene un problema que queremos resolver. Él sabe lo que le duele, y si queremos darle una solución, tenemos que hacerle protagonista. Ponerle en el centro. Ahí entra la investigación, la empatía, el trabajo de campo, el “humble inquiry” que decía Schein. Tenemos que dejar atrás nuestros prejuicios, nuestras “ideas de salón”, nuestra prepotencia de directivo/consultor, nuestro “yo sé lo que necesitan”. Tenemos que dedicar tiempo y recursos a escuchar, a entender.
  • Que tú no importas. Porque, claro, lo que importa es el usuario/cliente. No es tu punto de vista el que hace una idea buena o mala. No tienes que convencer a nadie de “tu idea”. Tienes que desprenderte de tu ego, estás ahí para entender al otro y para ofrecerle propuestas que él comprará o no. Y eso no es bueno ni malo para ti, eres un simple facilitador del proceso. He oído usar la metáfora de que “no somos vendedores, somos antropólogos”. No buscamos validación, no buscamos “acertar”, no buscamos “demostrar” lo buenos que somos. Cuando un usuario nos dice no a algo no está cuestionando nuestra valía, ni nuestra experiencia. No tenemos que sentirnos heridos, no tenemos que resistirnos a sus “noes” ni tratar de conseguir “síes”; simplemente tenemos que entender por qué el no es no, por qué el sí es sí.
  • Que hay que hacer pruebas con fuego real. Prototipado. Constante, y rápido, y barato. El objetivo es probar tus asunciones y tus propuestas, dejar que el usuario/cliente lo vaya validando, ver lo que funciona y lo que no y construir sobre ello. Eso implica abandonar la idea del “producto terminado”, de “lo perfecto”. Implica poner encima de la mesa algo para probar, algo con “errores”. Pero es que no son errores, es una herramienta útil para lograr un objetivo mayor. Hay que despojarse de la noción de que “esto está mal”. No es un examen que apruebas o suspendes, no es algo en lo que fallas.
  • Que reconoce ser un proceso desestructurado. A la hora de enseñarlo, los expertos del design thinking hablan de varias fases (empatizar, definir, idear, prototipar, probar), pero también advierten de realmente no son “pasos” que se desarrollen de una manera secuencial. Puedes ir hacia adelante, volver hacia detrás, empatizar mientras pruebas, idear mientras prototipas. Es todo un “magma” de principios en aplicación constante y concurrente. “Design is messy” es una frase que he escuchado decir durante un curso. Y me encanta. Porque así es la vida real. Messy, tirando a caótica. Lo importante son los principios, la dirección global.
  • El sesgo hacia la acción. Haz cosas. Deja de dar vueltas a la cabeza en la comodidad de tu despacho, y echa la bola a rodar. Las ideas son un espejismo, nos engañan haciéndonos pensar que estamos “haciendo algo”. Pero el mundo real solo cambia gracias a la acción. Y es sucio, sí. Y hay conflicto, sí. Es mucho más difícil que ver los toros desde la barrera. Pero sin eso, no hay nada.

Creo que es el camino correcto. Pero tengo que hacer una confesión: quienes me conocen saben que tiendo a la prepotencia y al egocentrismo. Yo sé. Yo tengo razón, mi punto de vista es completo, “quita, déjame que ya lo hago yo”. Llevo mal las críticas, que me digan que algo no lo he hecho bien, la falta de control, el equivocarme y el caerme. Tiendo también a estar cómodo y calentito en el mundo de las ideas (donde todo es más fácil y controlable, donde es más fácil “tener razón”), y me cuesta más “pasar a la acción” con su cuota de esfuerzo y frustración. Por todo eso, aplicar principios del “design thinking” supone un reto para mí. Pero también lo digo; creo que es un reto que merece la pena.

Contenido relacionado:

Continue Reading

Estar a la última vs conocer la esencia

El otro día comentaba una compañera que, en un encuentro sectorial, se había sentido en cierta forma “deslumbrada” por la palabrería que utilizaban los demás asistentes al referirse a su día a día, a sus procesos y herramientas de trabajo. Y había vuelto con cierta sensación de inferioridad, con la idea de que lo que nosotros hacíamos era menos interesante, menos moderno. Que estábamos varios pasos por detrás.

Me hizo pensar. Yo vengo precisamente de ese mundo. Del mundo de las consultoras chachiguays, de las metodologías diseñadas en Chicago, del “state-of-the-art”, de los anexos con “marca registrada” que justificaban ante los clientes que algo pasaba a valer uno o dos ceros más que lo mismo hecho por el despacho del señor Pepe. Y que lógicamente había que cambiar cada año o cada dos, para seguir dando la sensación de novedad, de innovación. Y mi sensación (que el dios de la consultoría me perdone) es que es algo bastante parecido al juego del mago de Oz. Si recordáis el libro o la peli, el Mago de Oz aparentaba ser un ente poderoso capaz de grandes prodigios desde su refugio en la ciudad Esmeralda. Sin embargo, era todo pura apariencia, trucos de ilusionista; en realidad no era más que un simple hombrecillo oculto tras una cortina.

A lo que voy es que, en mi opinión, muchas de las pretendidas innovaciones, metodologías rompedoras, novedades imprescindibles… en el mundo del management no dejan de ser rumiaciones y regurgitaciones de las mismas ideas básicas, puestas del derecho y del revés, una y otra vez. Ahora las llamamos con estas siglas, ahora con estas otras. Ahora las vinculamos con esta metáfora, ahora con esta otra. Ahora las dibujamos con un círculo, ahora con una estrella, ahora con una espiral. Aparentemente son distintas. Aparentemente son nuevas. Pero a nada que rascamos, nos damos cuenta de que son los mismos conceptos básicos. Los mismos perros con distintos collares.

No lo sé. Igual es que me estoy volviendo mayor. O más cínico. Pero creo que cada día es más importante obviar los fuegos artificiales, y centrarse en las cosas esenciales. Y como decían los clásicos, ahí no hay demasiadas cosas nuevas bajo el sol…

Contenido relacionado:

Continue Reading

Haciendo un mapa mental

Hace un tiempo que tomé contacto con el concepto de “mapa mental” (mind mapping), desarrollado por Tony Buzan. Lo vengo usando a nivel “conceptual” para gestionar proyectos, para elaborar contenidos (artículos, charlas)… y la verdad es me gusta como herramienta. Pero hasta hoy no había hecho un mapa mental “completo” (el que he usado para el post sobre networking).

Efectivamente, hasta hoy lo único que hacía era utilizar la idea básica del “mapa mental” (conceptos conectados de forma radial a partir de una idea principal). Pero lo hacía con boli y papel, únicamente con palabras y líneas. No había dado “el siguiente paso”, que para Buzan es parte intrínseca de la herramienta, consistente en añadir un componente gráfico (colores, dibujos, formas…). Para Buzan, gran parte de la gracia de los mapas mentales está en el aspecto visual, que por un lado nos permite elaborar/relacionar/caracterizar más los conceptos (ya que mientras dibujamos entra en juego nuestro “lado derecho del cerebro”) y por otro nos permite recordar mejor el conjunto del mapa (ya que lo vinculamos a imágenes, mucho más recordables para el cerebro).

Francamente, es un reto dar ese paso. Requiere tiempo, imaginación, unas habilidades que normalmente no tenemos desarrolladas, varias idas y venidas hasta conseguir cierta coherencia… pero a la vez tiene un punto divertido, para qué nos vamos a engañar. Y el truco es que, mientras estás pinta que te pinta (Buzan recomienda papel y pinturas… yo me he ido directamente al ordenador) sigues en realidad dándole vueltas a los conceptos y relaciones que estás intentando plasmar.

¿Son eficaces los mapas mentales? Yo creo que sí. Pero no porque en sí mismo sean una “herramienta superior” (me desmarco aquí de Buzan, que viene a decir que los mapas mentales son la octava maravilla, que sirven para todo, que “reflejan la forma de pensar del cerebro”; aunque sin duda cosas interesantes tiene). Al final, elaborar un mapa mental exige para empezar una labor de filtrado, priorización y relación de ideas. Es decir, que en ese proceso vas haciendo tuyo el tema que estés tratando, interiorizándolo, dándole sentido y forma. Un proceso de lectura, análisis y síntesis que, en sí mismo, ya tiene un valor notable. Y la fase de “embellecimiento” lo que hace es consolidar todo eso; sobre una estructura conceptual ya fijada, te dedicas a repasar y a complementar el sentido de las palabras y las relaciones con elementos gráficos que ayudan a fijarlo.

Como ocurría con los resúmenes en la época de estudiante, creo que la mayor parte del valor del mapa mental no está en el resultado, sino en el proceso. Es ahí, mientras lo estás elaborando, cuando haces el trabajo. Observar un mapa mental ajeno, por lo tanto, tiene un valor limitado. Puede ser más o menos bonito/curioso, más o menos coherente… pero todo el conocimiento que se esconde detrás sólo está al alcance de quien lo elaboró.

Contenido relacionado:

Continue Reading

Modelos, metodologías y otras paparruchas

Hace ya algún tiempo (mucho… es de los primeros posts del blog) hice una reflexión sobre las metodologías usadas, habitualmente, por los consultores. Hoy, casi cuatro años después, vuelvo sobre el tema.

Y es que los consultores somos muy dados a crear “modelos” y “metodologías”, que se resumen en unos gráficos con unos cuantos bloques, unas cuantas flechas, unos cuantos colores y unas cuantas palabrejas extrañas. En teoría, nos decimos, sirve para transmitir de forma gráfica un concepto complejo… pero yo creo que lo cierto es que la mayoría de las veces sirve para enrollarse durante mucho tiempo para contar alguna perogrullada que no costaría contar más de medio minuto acodados en la barra del bar.

Pero claro, un modelo mola mucho más. Demuestra lo listos que somos, lo mucho que discurrimos. Demuestra que realmente sabemos, y que merece la pena pagar por nuestros servicios (“¡eh, que tenemos ‘el modelo’!”). Y más cuando tenemos un modelo exclusivo, hasta patentado en muchas ocasiones. Citándome a mí mismo, “los consultores utilizan sus ‘inventos’ como un presunto elemento de diferenciación, la demostración más palpable de que su trabajo va a ser mejor que el de otros”.

No tengo problema en que se utilice un modelo para explicar un concepto. Lo que me molesta es cuando se eleva el modelo a categoría de tótem. No. Lo importante es el concepto, no el modelo. Y si podemos explicar el concepto sin más parafernalias, lo demás sobra.

Contenido relacionado:

Continue Reading

Diez consejos para hacer una buena propuesta

La elaboración y presentación de una propuesta es uno de los pasos más importantes en el proceso de venta de servicios de consultoría. Por supuesto, viene precedida de una labor de marketing más o menos segmentada, y de un acercamiento inicial al cliente que ya resultan bastante determinantes. Pero la propuesta es “la hora de la verdad”, el momento en el que todas las conversaciones y acercamientos previos se tienen que plasmar en un documento que va a servir para que el cliente tome la decisión sobre contratarnos o no.

Estos son algunos consejos (derivados de mi experiencia y por lo tanto totalmente debatibles) para hacer una buena propuesta.

Sé visual: la propuesta tiene que hablar por sí misma por lo que, además de cuidar el contenido, debemos cuidar el continente. Nada de párrafos y párrafos de texto abigarrado: usa fotos, colores, cuadros, espacios en blanco… se trata de que resulte agradable de leer y de generar buen recuerdo en el lector.

Sé conciso: posiblemente haya varias personas que tengan que decidir sobre la propuesta. Directivos con poco tiempo y pocas ganas de leer “tochos”. Así que sé lo más directo que puedas. Trata de dividir la propuesta en una parte “ejecutiva” y, si tiene sentido, incluye anexos para quien quiera profundizar.

Sé comprensible: haz que la propuesta se entienda por sí misma. Piensa que habrá quien la lea (y quien tenga que decidir sobre ella) que no tiene por qué tener profundos conocimientos técnicos al respecto. As� que trata de utilizar un lenguaje lo menos técnico posible, explica los acrónimos y evita entrar, en la medida de lo posible, en detalles técnicos sin relevancia.

Personaliza: la propuesta es para un cliente concreto, no una propuesta genérica. Personalízala al máximo: introduce el logo del cliente, nómbralo con frecuencia, utiliza fotos que se refieran al cliente y a su negocio, si pones ejemplos adáptalos a su negocio… cualquier cosa que evite que el cliente piense que está leyendo “una propuesta estandar”.

Contextualiza: dedica tiempo (y espacio en el documento) a contextualizar el proyecto. A explicar por qué tiene sentido para este cliente concreto en este momento concreto, y en qué le va a ayudar a conseguir sus objetivos. Háblale de su negocio, de sus necesidades, y de cómo el proyecto encaja con todo ello. Si consigues darle contexto, será mucho más fácil que lo compre.

Ajusta el precio: siempre hay un margen de negociación entre el precio que ponemos en la propuesta y el precio final. Pero debe ser un margen acotado. Si resulta que durante el “regateo” llegas a un precio sensiblemente inferior al que planteas en la propuesta, estarás trasmitiendo un mensaje de “te estaba intentando engañar” que no te deja en muy buen lugar.

No abuses de metodologías: es difícil, por no decir imposible, que un cliente se lea la descripción prolija de todas las fases, subfases y tareas que piensas incluir en tu proyecto. Se supone, para eso eres profesional, que es cosa tuya. Además, todos sabemos (nosotros y ellos) que las metodologías saltan por los aires en el minuto 1, así que no tiene mucho sentido hacernos fuertes con algo que luego no va a responder a la realidad.

No mientas (demasiado): en una propuesta podemos tener tendencia a engordar artificialmente los recursos que vamos a dedicar, la experiencia de los consultores, las referencias utilizadas, la dedicación de los socios, la infalibilidad de la metodología… evita hacerlo en la medida de lo posible. Primero, porque se nota. Y segundo porque, si luego la realidad no responde a lo prometido, estaremos generando una experiencia muy negativa en el cliente. Quizás ganemos esta propuesta, pero nos estaremos poniendo una zancadilla a nosotros mismos para el futuro.

No seas reglamentista: no trates de convertir la propuesta en un contrato con todo tipo de cláusulas y articulado. Las relaciones cliente-consultor y la evolución de los proyectos siempre superarán la mejor de tus previsiones y no quedarás cubierto, mientras que al cliente le puedes estar poniendo una barrera; ¿tú no has sentido rechazo cuando te ponen delante un contrato con montones de letra pequeña?. Además, ¿y si el cliente dice, simplemente, “no me gustan estas cláusulas?. No hay mejor contrato que una relación de confianza entre cliente y proveedor.

No te des autobombo: la propuesta no es el sitio en el que contar las excelencias de tu empresa, el abanico de tus servicios o los clientes tan guays que tienes (total, al final todos siempre ponemos los mismos). Eso ya lo has debido hacer en el proceso de acercamiento previo, por eso te piden una propuesta. Ahora céntrate en el proyecto y en cómo tu empresa va a abordarlo. Todo lo demás es accesorio. Si quieres, entrégale otra presentación o brochure. Pero no mezcles churras con merinas.

Contenido relacionado:

Continue Reading

La nieve y las metodologías

Hay que fastidiarse con el temporal de frío polar… ¡¡al final iban a tener razón los de Protección Civil!!

Ayer mientras viajaba, contemplando la nieve que caía alrededor, no pude por menos que hacer una reflexión que hoy traigo aqui. Dicen los que saben de esto que es difícil, por no decir imposible, encontrar dos copos de nieve iguales. La estructura de cristales que los compone se forma de tal manera que la hace irrepetible. Así, cada copo de nieve resulta único…

Las empresas, en este sentido, son como copos de nieve. Lo que es cada empresa en la actualidad está definido por un número tal de factores que hace imposible encontrar dos iguales. Desde la personalidad de su fundador, pasando por las circunstancias históricas que haya atravesado, al impacto que cada una de las personas que se han relacionado con ella (trabajadores, clientes, proveedores, competencia), las decisiones estratégicas que se han tomado… son elementos que configuran un ente único, irrepetible, como es cada una de las empresas existentes.

Si uno asume esta realidad (lo difícil sería no hacerlo), resulta extraña una de las costumbres más arraigadas de los consultores: las “metodologías”.

Casi todos los consultores del mundo dedican una ingente cantidad de recursos (tiempo de sus profesionales, dinero, materiales, instalaciones…) a la elaboración de metodologías. Las empresas más grandes, incluso, dedican recursos a tiempo completo a esta tarea, creando “El Centro para la Excelencia” y cosas similares. Todos estos esfuerzos cristalizan, en un momento u otro, en la plasmación de dicha metodología en un esquema más o menos sencillo, una especie de “receta” o “guiaburros” que promete, con la solvencia que le dan todos los expertos que hay detrás de su elaboración, una especie de “solución universal”, una piedra filosofal que permita, por su mera alicación en una empresa, la resolución de los problemas que pudiesen aquejarla.

Estas metodologías se convierten así en la piedra angular de la labor de muchos consultores. La incluyen en todas sus presentaciones, propuestas, folletos de publicidad… habitualmente, la metodología es patentada y eso se proclama a los cuatro vientos como un elemento más que demuestra su exclusividad. Y si es exclusivo… tiene que ser bueno. Así, los consultores utilizan sus “inventos” como un presunto elemento de diferenciación, la demostración más palpable de que su trabajo va a ser mejor que el de otros. Y, en consecuencia y para ser coherentes consigo mismos, cuando abordan un trabajo lo hacen siguiendo su metodología contra viento y marea.

Pero… ¿no habíamos dicho que cada empresa es un ente completamente único? Entonces… ¿cómo es posible que los consultores insistan en vender y aplicar, como algo diferenciador, una metodología que se basa precisamente en eso, en un procedimiento “estándar”?.

Como cualquiera que se haya metido alguna vez en una cocina sabe, las “recetas” no determinan hacer un buen plato. Pueden ser una guía, sí. Pero lo fundamental, cuando se cocina, es la capacidad del cocinero, su sensibilidad para captar los matices de los productos, para ajustar las cantidades de los ingredientes, para alcanzar el punto exacto de cocción, para adaptarse a las características de su cocina o para dar ese toque adecuado para el comensal. La cocina es, en el fondo, un oficio artesano, y nunca un proceso industrial (regido por una “receta” que se aplica una y otra vez) podrá alcanzar los matices de un buen artesano…

En consultoría, en fin, pasa exactamente lo mismo. Aplicar una metodología es la forma “industrial” de abordar un proyecto. Es más sencillo, sí, ya que se trata de seguir unos pasos preestablecidos. Y más barato, y rentable por lo tanto, porque casi cualquiera puede seguir una metodología, incluyendo consultores con poca o ninguna experiencia. Sin embargo, la calidad de la solución nunca podrá ser la misma que la proporcionada por un consultor experto que, por encima de la metodología, es capaz de poner su sensibilidad, su conocimiento intrínseco y, en el fondo, su oficio, a disposición esa entidad única, irrepetible y maravillosa que es cada empresa.

Yo, desde luego, si fuera un copo de nieve pediría a mis consultores que me tratasen como tal.

Contenido relacionado:

Continue Reading