Todo empezó con un artículo de Luis sobre los últimos momentos de un proyecto y la motivación. Coincidía con un arranque y no pude evitar ver los paralelismos.

Me refiero a los "flecos" del proyecto. Esa lista, inicialmente pequeña, de "mejoras" que quedan pospuestas durante el desarrollo del proyecto. Lista que crece exponencialmente según se acerca el arranque y se hace evidente que no hay tiempo para todo. Entonces, pequeñas ayudas, pantallas de simplificación de procesos, listados.... se van quedando para la "Fase II".

Luego llega la fecha de arranque, que más o menos sale bien. Y, cuando se recupera la calma, aparece alguien con "la lista". El equipo que estaba motivado y "con las pilas puestas" para completar algo y que ha llegado exhausto al arranque, se encuentra con una lista de tareas poco agradecidas y nada motivantes que hay que afrontar.

Y a ese escenario hay que añadir el factor de los costes económicos. Si el proyecto está externalizado, toca discutir si esa fase II se debe a incrementos de funcionalidad, a errores de estimación o a otras razones. Pero, en el fondo, se discute quién paga esas horas que faltan por ejecutar. Si es interno, la valoración económica es menos importante, pero la dificultad de gestionar el cansancio y la motivación es la misma.

Lo cierto es que tiene poca solución. Cuando el proyecto es interno, nosotros intentamos incrementar la carga de esa Fase II con nuevos alcances, funcionalidades o tecnologías que aporten algo de motivación (la consulta web de datos, presentación gráfica, transacciones desde PDA o Blackberry,...). Es la forma de añadir alegría a una tarea poco agradecida y así intentar mantener la motivación.

Pero en proyectos externos, esto no es sencillo, ya que estás planteando un nuevo escenario y ese nuevo alcance implica costes que no quieres/puedes asumir. Y que, por supuesto, tu proveedor tampoco asumirá sólo (lo siento, esta tilde la sigo poniendo) para mantener motivado a su equipo.

Aunque, cómo dice Luis, como alternativa puedes poner un poco más de RAM a los equipos ;-)

La foto es de Craig Miles, en Flickr.

Me provoca Raúl para que cuente lo que cambiaría de mis tiempos de consultor, ahora que estoy sentado "al otro lado de la mesa".

La respuesta es fácil: Nada.

Me explico. Me refiero a la parte de venta del proyecto. No venta en sentido de contrato sino en las reuniones y documentos en que intentas convencer al cliente de la necesidad o conveniencia de ejecutar ese proyecto (otra cosa es si eres tú o no el mejor proveedor para ello). De la ejecución hablaremos otro día.

Desde ese punto de vista de la oferta, yo participé en dos tipos de iniciativas: las que realmente valían y las que no. No hay término medio, es binario. En las primeras, era bueno. En las segundas, no. De hecho, era malo. Se me notaba cuando no creía en el proyecto. Y eso no es bueno para seguir progresando a determinados niveles.

Había proyectos en que era claro que el cliente saldría ganando: podía ser en el proceso, en la disponibilidad o calidad de la información, en los resultados económicos... Incluso podía ocurrir que él no lo tuviera tan claro, pero que visto desde fuera era más que razonable entender que se obtendría un beneficio de ese proyecto. En esos casos, era motivador explicar al cliente las ventajas, averiguar que le frenaba, porqué no se decidía...y luego vencer esos miedos demostrando los beneficios esperados.

En estos casos cambiaría poco de lo que hacía. Quizás, ser más práctico y menos teórico. Presentar más propuestas en que se facturara, al menos una parte, por éxito. Pero son más aspectos formales que de fondo.

Pero había otros casos en que no era todo tan bonito. Y fueron los que marcaron el final de mi carrera en consultoría. Cuando vendías o intentabas vender una solución para un problema inexistente. Reconozco mi incapacidad de convencer a un cliente de la necesidad de algo en lo que no creo, igual que me ocurre ahora si presento un proyecto a mi director general.

Recuerdo algunas ofertas en las que era casi imposible lograr algo positivo para el cliente. O había intereses con algún partner o se necesitaba estar en el cliente como fuera o se trataba sólo de facturar horas de desarrollos imposibles. Esos casos son los que no me gustaban y los que ahora, cuando intentan venderme algo así, me disgustan profundamente. Un ejemplo reciente: para un equipo de cuatro programadores propios, con muchos años de experiencia, vender una metodología y software de control de calidad del software y de pruebas unitarias. Cuando hace un par de años teníamos proveedores externos, freelance y proyectos cerrados simultáneamente, esto tenía sentido. Ahora no. Y si, después de que te he contado mi situación actual y la evolución de la misma, sigues en el intento de venderme eso, dejo de creer en tu buen criterio. Y eso es difícil de recuperar.

Esto es lo que cambiaría. Seguramente por eso, aunque volviera a consultoría, no lo haría bien. Tampoco valdría para vender coches usados ;)

Tengo que reconocer que hasta el último trimestre de 2009 no empecé a ver de cerca la cara real de la crisis. Hasta ese momento, sólo eran noticias en prensa o TV, pero en ese periodo coincidí con varios amigos y excompañeros que habían quedado en paro. Todos ellos buenos profesionales, con brillantes carreras en consultoría y luego en clientes, puestos directivos en su mayoría...

Pensé en escribir sobre ello, pero no sabía siquiera que enfoque darle. Ahora he recibido un correo que me ayuda, basta con copiar y pegar. Gente como Andrés, Alfonso y muchos más explican esto mucho mejor. Pero creo que una experiencia directa puede ayudar. Mi única aportación ha sido marcar en negrita lo que a mi me parece más importante.

Buenos días a todos

¿Qué he aprendido en estos 232 días?

• Cómo hacer y personalizar un CV
• Cómo hacer una buena entrevista de trabajo
• Cómo mover el networking entre amigos y conocidos
• Que las webs de empleo sirven de muy poco.
• Cómo negociar un contrato de trabajo
• Cómo se lleva la Dirección Académica de Operaciones en una Escuela de Negocios
• Cómo hacer el Camino de Santiago en bici
• Un poco de francés (idioma)
• Que no soy un manta porque me rechacen en un puesto de trabajo ni un fiera porque me quieran en tres procesos

Pero sobre todo he aprendido que:

• Las empresas no lo son todo en la vida (ni mucho menos)
• Las personas son mucho más importantes
• Cuento con una agenda de amigos fantásticos
• La familia es imprescindible

Uno de los grandes principios del Networking es agradecer lo que se ha recibido, por ello aprovecho para daros las gracias por:

• Los CV recibidos y remitidos
• Los cafés compartidos
• Las comidas saboreadas
• Las charlas degustadas

Para acabar de celebrarlo, vamos a tomar una cervecita en un local cercano a mi casa que es bastante tranquilito:

Espero que sirva de ayuda para alguien.

(Este post es un poco viejuno y había quedado como borrador. Pero quiero retomar esto y retocar algo es más fácil que empezar de cero. Poco a poco).

Hoy he tenido una experiencia que hacía mucho que daba por desaparecida del mundo consultoril, tras ser la práctica habitual hace 10-15 años (yo la viví desde el otro lado).

Me refiero al consultor "sabelotodo" que intenta vender una solución integral, sofisticada y definitiva para un problema que no tienes. En este caso particular, buscábamos soporte a un pequeño piloto de reporting y agregación de información entre sistemas y nos quería vender la cojo-aplicación de Business Intelligence, con Data Mining y lote completo de Informes dinámicos, broadcasting, forecasting. En términos "de gerente", yo necesitaba una persona a tiempo parcial un mes (incluso algo menos) para dar soporte sobre un producto opensource y él me quería colocar dos personas dos meses (más el overhead) y un producto de primera línea mundial (y licencias en k$).

Es cierto que hay que ser ambicioso cuando lanzas un proyecto y que tienes que intentar mirar un poco más allá de tus necesidades actuales. Pero no creo que Raúl haya contratado un almacén robotizado de 20.000 metros cuadrados y trilaterales filoguiadas para gestionar el stock de Triopic. Sería fantástico para él, pero hoy por hoy creo que no lo necesita (ójala dentro de poco si, y que nos lo subcontrate a nosotros).

Recuerdo que está actitud de vender el lote completo era habitual hace 15 años. Llegabas a un cliente y le colocabas lotes completos de productos en los que sólo llegaba a utilizar el 25% de la funcionalidad. No digo que engañaras al cliente, pero si es cierto que le proporcionabas un cañón para matar moscas. Quizás, te justificabas, un día tuviera que luchar contra Stukas.

En la mayoría de los casos, tu comprador era un experto en el negocio con un desconocimiento importante de la tecnología. Además, los productos eran más difícilmente modulables y la implantación completa, mucho más cómoda que la parcial. Para completar la jugada, el número de opciones era muy limitada.

Pero ahora creo que eso es más complicado. Los productos son, casi todos, más modulares. Además, existen más alternativas (basadas en productos open o en cloud). Y, sobre todo, cualquier persona (vale, casi cualquier) que está en un negocio tiene una base tecnológica, aunque sea sólo basada en la experiencia, que hace complicado "colar" algo injustificable.

Por eso me ha sorprendido tanto este regreso al pasado. No sé si el tipo nos ha considerado muy jóvenes e inexpertos (está mal decirlo, pero no aparento los años que tengo ;-) ) y ha querido apabullarnos. O está loco por vender y ha buscado el lote completo a la primera. Pero desde luego, ha conseguido desacreditarse por completo.

Hasta aquí, lo escrito antes de Navidad. Hoy me envía un correo que me confirma que no entendió nada, proponiéndome montar el proyecto en una factoría de Sudamérica. El coste de montar un equipo para empezar algo así es imposible que se justifique para lo que yo necesitaba, aunque si para lo que él quiere vender.

En primer lugar, aclarar que aunque el término se refiere, en origen, a los consultores de la antigua Arthur Andersen, luego Andersen Consulting (desaparecida incluso de Google), es casi utilizable para cualquiera de las Big Four (antes, Five). Seguimos...

Cuando en 2003 empecé el MBA, una de mis compañeras de grupo me soltó, a los dos o tres días de conocernos "Es que tú eres normal, no pareces un arturo".

Mucho antes de eso, en muchos clientes había oido de forma más o menos directas o, simplemente, al pasar junto a la máquina de café, comentarios, generalmente despectivos, sobre "los arturos". En algunos casos, se utilizaba también en el mismo sentido términos más generales como "los consultores" o, en entornos menos considerados (por ejemplo, almacenes logísticos), "los encorbatados estos".

Siempre me ha parecido una generalización bastante injusta (como todas). Pero tras unos cuantos años fuera del entorno, a veces te descubres pensando lo mismo que pensaban los que te veían entonces.

Hace unos días vino un consultor de una de estas grandes a una entrevista de trabajo. Le entrevistaban dos personas que, casualmente, habáin trabajado en empresas de ese tipo. Precisamente por eso, no podían dejar de reirse al comentar la entrevista y los términos que utilizaba "el arturo": "quiero pasar a cliente final", "¿cúal es la denominación exacta del puesto?", "¿a quién debo "reportar"?", "¿cuales son las funciones y necesidades del puesto?", "¿cúal será la estructura de mi equipo?"...Todo con mucho sentido para una descripción del puesto o un proyecto de reingeniería de procesos.

Pero la vida real, en la mayor parte de las empresas (dejaremos fuera a las del IBEX-35 y alguna más), es más complicada. Menos estructurada y más flexible. Y el responsable de Asesoría Jurídica tiene que echar una mano a algún consejero con sus escrituras, o el de logística tiene que organizar la mudanza del CEO de un cliente, o el responsable de TIC tiene que mandar a un agente de CAU a casa de un consejero para ver porque "no va la wifi". Y, además de esas anécdotas, te tienes que preocupar de que las cosas salgan adelante. Aunque esa decisión no sea de tu departamento o la solución a un punto abierto dependa de otros. Tienes que ocuparte de llenar los vacíos que quedan en los procesos para completarlos, porque aunque no figure en la descripción del puesto, hay que hacerlo. Y no importa nada el quién.

Lo que me resulta llamativo es lo lejos del MundoReal que se puede llegar a estar. Yo tuve la suerte de trabajar en proyectos con todo tipo de personal de los clientes, con directores generales y con mozos de almacén. Y es algo que agradecí mucho. Cuando estás tres noches seguidas con los mozos y responsables de un almacén, la percepción de la logística y de los sistemas que se necesitan tiene poco que ver con la que te cuenta el Director de Aprovisionamiento en la sala de reuniones de la planta noble. Y si solo has estado en esas reuniones, terminas convirtiéndote en ese estereotipo, casi caricatura, por el que a veces nos identificaban. Y realmente es injusto para los muchos consultores que han (hemos) estado en proyectos trabajando junto a operadores de CAU, mozos de almacén, cajeros de sucursal bancaria, comerciales de telefonía, etc...y es que no todos eramos "arturitos pata-negra de despacho de consejero delegado".

Como conclusión, esa caricatura está asociada a la rigidez, al seguimiento estricto del modelo. Y creo que hoy, incluso con independencia del tamaño de la compañía, se necesita flexibilidad, capacidad de adaptación (que es algo que puedes y debes aprender en consultoría). Y si no eres capaz de hacerlo y de transmitir esa imagen, tienes un problema.

PD: Y he sido algo indulgente al no comentar nada sobre el corte de pelo estándar, el traje y la camisa estándar, la corbata estándar y la llegada y salida en taxi hasta la puerta.

El pasado sábado tuve la suerte de compartir aula con Jose M. Pelaez, en el Executive MBA en dirección de Operaciones y Logística del que es profesor. Puede asistir como oyente a una de sus clases sobre Sistemas de Información en Operaciones Logísticas.

Además de lo agradable de poder escuchar y compartir las tres sesiones con José Mª, fue una interesante experiencia volver a las aulas, en este caso de una escuela de negocios, para tratar con gente de cursos de postgrado.

La audiencia era de perfil poco generalista (menos de lo que yo recordaba de mi MBA del IE), ya que la mayoría eran ingenieros trabajando en operadores logísticos.

En todo caso, uno de los aspectos más enriquecedor de la experiencia fue recordar los "vicios" típicos de los ingenieros, especialmente de los que trabajamos en Sistemas de Información. Y el fundamental es creer que los sistemas lo arreglan todo. Es más, realmente, suelen arreglar bastante poco. Si tus problemas son de operativa o de sistemática, los ordenadores no te van a ayudar. NO. Lo diga el consultor que lo diga o el proveedor de ERP que lo diga.

Y aunque con los años te das cuenta de eso, de vez en cuando tu afán "cuadriculador" vuelve e intentas arreglar todo cerrando las puertas del sistema. Pero la realidad siempre es más compleja. Ese es el momento en que los usuarios se quejan de "que no pueden trabajar" y los informáticos de que "para que hemos hecho esto si sólo tiene agujeros".

Uno de los primeros gerentes que tuve en consultoría (ingeniero de Teleco, para más señas) decía siempre que "los sistemas de información tienen que ser siempre modelos y, como tal, reductores de particularidades". Como base teórica es excelente, pero los procesos (en general) requieren cada vez más personalización, más adaptación al cliente y, por tanto, tienen cierta tendencia a des-estandarizarse.

Por eso, cada vez más, creo que hay que ir a sistemas de información flexibles y rápidos, aunque eso pueda suponer ir contra los dogmas de la teoría. Ni el código podrá ser todo lo limpio que nos gustaría, ni las bases de datos estar tan normalizadas como dicen los manuales. Recientemente, hemos puesto en marcha una aplicación que sólo sirve para facturar al 90% de nuestros clientes. Pero para llegar al 100% de los clientes, hubiéramos necesitado mucho más tiempo de análisis y desarrollo (varios meses) para, seguramente, tampoco lograr la perfección. Y creemos que es mejor facturar hoy automáticamente ese 90% que, dentro de 8 meses, tener la posibilidad de llegar al 100.

Y no creo que esto sea una chapuza. Los sistemas no van a durar 20 años, como cuando se hacían en Cobol hace 40 años. Como decía Ampara Moraleda, "cada vez nos pasan más cosas por unidad de tiempo" (gracias, Luis, por la cita). Y a las empresas, también. El ritmo de modificaciones es tan rápido que el coste de hacer "perfectas" las cosas sólo supone retrasar el inicio de la siguiente modificación, detectada cuando aún no has terminado la primera.

Es cierto que esto supone un mayor esfuerzo por nuestra parte (la de "los de sistemas"), pero es la única forma de no ser un freno a la innovación de los procesos en nuestra empresa y convertirnos en un facilitador de esos nuevos negocios que, necesariamente, tendrán que apoyarse en nuestros programas y nuestras bases de datos.

El segundo aspecto llamativo de la sesión fue la separación entre la gestión empresarial (entendida como objetivo de los propietarios o administradores) y la gestión del día a día (las operaciones, los costes, etc.). Pero eso lo dejaremos para otro día.

NOTA: La foto está tomada de una clase, en el blog de Enrique Dans.

Un atinado comentario de Sergio en el post anterior sobre las rebajas de precios, me ha recordado un lúcido análisis de Angel sobre el coste de un consultor y, como consecuencia, sobre cuanto debe costar un proyecto o, mejor dicho, ¿a cuanto hay que vender un proyecto?

Sobre este tema ya ha escrito mucho Luis, pero me gustaría añadir una idea, que proviene de una experiencia personal.

La forma más sencilla de poner el precio a un proyecto de consultoría es empezar por estimar el esfuerzo necesario en horas de cada perfil (programador, analista, etc...). Luego se añade un coeficiente de incertidumbre que depende de si conocemos bien al cliente o no, si creemos que sabe lo que quiere, si la tecnología es o no madura, etc.

A eso se le añade un porcentaje de supervisión (el temido overhead), que son las horas de gerente, socio, etc.. Con eso tenemos el precio "base" al que podremos hacer un descuento por interés en entrar en el cliente, por ser una buena referencia para el futuro, etc.

Pero como dice Sergio, no hemos hablado apenas del cliente. Puede ocurrir que el precio así calculado sea 100 (por usar una base). Pero podemos hacer que el cliente ahorre 500. ¿Cuál debería ser el precio entonces? ¿Tiene sentido una rebaja de última hora en un proyecto así?. Y si el proyecto no va a tener un impacto positivo claro para el cliente, ¿debemos hacerlo? ¿hay que hacerlo barato y rebajar la calidad, con lo que el resultado será aún peor y perjudicamos nuestra credibilidad?. ¿O tiene sentido recomendar no ejecutarlo, beneficiando la credibilidad pero dañando nuestro resultado, al menos a corto plazo?. Estas son las preguntas que permitirán que la relación sea de confianza, el mejor criterio (el único?) para seleccionar a un consultor.

Y ahora una batallita sobre proyectos baratos o caros.

El proyecto más rentable en el que he trabajado para un cliente fue un desarrollo web. Estamos en el año 2000 ó 2002 (aprox.). Permitía a los proveedores consultar cuales de sus facturas habían sido revisadas, tenían o no incidencias y cual iba a ser la fecha de pago de la misma. Lo resumo con datos aproximados. Cuando tienes, por ejemplo, 2.000 proveedores, las llamadas para hacer esas consultas volvían loco al departamento correspondiente durante la semana anterior a la fecha de pago.

El desarrollo web costó menos de 15.000 euros en un mes de trabajo. Sumemos un servidor, unas licencias, un certificado de seguridad, etc. Pongamos coste total 30.000 euros (y me estoy pasando muuucho). Pero como los proveedores también se iban a ahorrar mucho tiempo de gestiones y llamadas, ¿qué tal si les cobramos un poco?. Sólo 50 euros/año. Ellos se van a ahorrar en teléfono y gestiones mucho más.

Resulta que el proyecto no sólo "se paga por si mismo", sino que convierte al departamento financiero en un centro de ingresos para la compañía. En este caso, está claro que el proyecto se vendió "barato". Si el consutlor es capaz de proponer la idea, valorar el impacto y que el cliente la acepte, puede vender el coste de desarrollo al triple de su coste real y, aun así, sería inferior al valor aportado.

No siempre es fácil evaluar el impacto económico de un proyecto en una compañía y el abuso de los Business Case de estos últimos años con ahorros imposibles (e increíbles) ha hecho mucho daño a la credibilidad de los mismos, pero no cabe duda de que hacerlo antes de presentar la propuesta evitará tener que hacer rebajas de última hora que implican un coste económico y de confianza que seguro que nos traerá complicaciones futuras.

NOTA: Curiosamente he podido ver que la web sigue activa, con esa letra Times sobre fondo sombreado típica de 2000-2002. Y ahora es multiidioma, por lo que supongo que el modelo se ha estendido a otros paises de esta multinacional. Sin duda, uno de los mejores proyectos TIC de todos los tiempos por rentabilidad para el cliente.

No me gusta regatear. Ni en mis compras particulares ni en las que aquí interesan, las profesionales.

Me parece que cuando pides propuestas estas deben reflejar lo que quieres al precio que el proveedor considera justo. Y espero que ese sea el precio del producto/servicio. No espero que luego si no es el elegido venga con un 5-10-20% de descuento. No me parece presentable. Si haces eso, no puedo evitar pensar que han intentado engañarme la primera vez.

Hemos pedido ofertas para un proyecto de cierto volumen, alrededor de 250.000 euros. Tras una selección entre cuatro, nos quedamos con dos propuestas casi idénticas en tecnología y precio (menos de 1.000 euros de diferencia).

Comunicamos al ganador y al finalista la decisión, ya que antes de firmar el acuerdo definitivo hay que poner de acuerdo a una tercera parte, algo que no debe suponer ningún problema.

Y el "finalista" llama al día siguiente para comentar que tuvieron ayer reunión de no-sé-qué comité con no-sé-cual manager y que pueden aportar fondos promocionales para descontar un 10%. es decir, casi 25.000 euros.

Moralmente, me apetecería obviar la llamada y seguir con el plan inicial.

Pero si puedo ahorrar ese dinero a la empresa, creo que debo hacerlo. Y eso implica llamar al proveedor seleccionado y pedirle ese dinero. Lo cual me resulta muy incómodo a nivel personal y poco ético en lo profesional. Y más aún si me dice que no puede hacerlo.

Así que una mañana que debía ser tranquila, de revisión de detalles técnicos se convierte en dar vueltas a la cabeza sobre lo que está bien o está mal y sobre la ética de los proveedores y, por qué no, de los compradores.

NOTA: La foto es de juoerr (en Flickr)