Seleccionar página

Un presupuesto marca tu relación con los clientes y con tus equipos de trabajo. Si este documento está mal planteado, alguien, o todos se verán tarde o temprano afectados.

Aunque parece que no hay mucha controversia y no se justifica una entrada en el blog, al final de mis reflexiones entenderéis cual es la verdadera problemática que os planteo. No solo os plantearé el problema para que lo debatamos entre todos, sino que os aportaré m experiencia en cómo lo estamos resolviendo.

¿Qué significa “hacer un buen presupuesto”?

Creo que las claves de un buen presupuesto es la relación y equilibrio entre:

  1. Reducir las áreas de incertidumbre/riesgo todo lo que se pueda, tanto para nosotros como para el cliente.
  2. Tiempo de dedicación a presupuestar ya que por lo general no son horas “factuables” a los clientes.

Un buen presupuesto debe dejar claro a todas las partes que trabajarán en el proyecto qué se tiene que hacer, quién es el responsable, cuándo se tiene que hacer y cuánto cuesta hacerlo. Nosotros, personalmente, incluimos el por qué tenemos que hacerlo ya que esta pregunta nos ayuda a determinar las prioridades de esas especificaciones y si realmente son aspectos fundamentales para incluirlos en nuestros PMV (Proyecto Mínimo Viable).

Hasta aquí la teoría, con la que todo el mundo, más o menos, está de acuerdo.

Pero…¿Qué implica realmente hacer un buen presupuesto?

Por pura metodología (estamos implantando SCRUM, al menos lo intentamos), son los propios equipos trabajo los que deben valorar el tiempo esfuerzo que cada uno de ellos dedicará para hacer su parte del trabajo. Podría hacerlo una persona ajena, especializada en hacer valoraciones y presupuestos, pero ya se ha demostrado suficientemente que esto no funciona. Es mucho mejor que sea el propio equipo el que valore:

  • Los equipos se sienten mucho más comprometidos con sus propias decisiones que por las decisiones que les impone un “experto”. Además es lógico, si voy a ser yo quién desarrolle esa tarea, debería ser yo quien diga cuánto tardaría yo en desarrollarla. Para los responsables de desarrollo también es muy práctico, no te toca la fea tarea de imponer lo que piensas a los demás.
  • Cuando las valoraciones la hacen otros, las hace en función de su experiencia y habilidades, por mucho que tome en cuenta la media que tardan las personas en realizar esa tarea. Si esa persona es muy buena en hacer algo, tenderá a valorarla con por esfuerzo. Para que todo vaya bien, la persona que finalmente lo desarrolle deberá ser al menos tan buena como el “valorador”

Asumamos que es el equipo que finalmente desarrolla el trabajo el que debe valorar el esfuerzo para establecer un precio en el presupuesto. Esto implica juntar a un equipo de personas cada vez que un cliente nos pida un trabajo, alguno de ellos externo a la empresa (proveedores) que debe “donar su tiempo” para ofrecerle al cliente una propuesta ajusta a la realidad. ¿Os parece justo?. Yo creo que no, no puedo pedirle a los proveedores que asuman ese coste comercial sistemáticamente ni puedo pedirle a los clientes que paguen esas horas de valoración, al menos ahora y en Extremadura.

Por otro lado, reunir a un grupo de personas (como poco nosotros requerimos a 4-5 personas para proyectos sencillos) conlleva un tiempo para cuadrar las agendas de todos. Una vez reunidos, valora el trabajo que se está pidiendo y redacta una propuesta que contemple el mayor número de especificaciones. Esto pueden ser unas 8 horas de trabajo, si el trabajo no es muy complicado. Todos estos tiempos incrementan el plazo en el que le podremos entregar el presupuesto al cliente.

Otro factor añadido es preparar la reunión de valoración. Debemos reunirnos con el cliente, capturar lo mejor posible lo que el cliente quiere que hagamos, entender muy bien los objetivos, entender por qué nos piden las especificaciones de producto que nos están solicitando, redactarlo correctamente para que todo el equipo de valoración lo entienda correctamente (siguiendo los principios de INVERC – Independent+Negotiable+Valuable+Estimable+Small+Testable).

Como podéis ver, el coste empieza a multiplicarse, son muchas horas de muchas personas para poder presentar un “presupuesto responsable”. Qué ocurre si al final el cliente no acepta nuestro presupuesto. ¿Es aceptable asumir ese riesgo? ¿Es honrado pedirle a nuestros colaboradores que asuman ese riesgo?.

Hasta el momento, el escenario no es muy positivo. Demasiadas cosas por hacer, con un grado de incertidumbre elevado.

Pero… ¿cuáles son las consecuencias de no hacer los presupuesto bien?

Entenderemos que “bien” significa todo lo anterior, valorar, reuniones de especificaciones, redacción INVERC… todo lo que hemos indicado hasta el momento.

Aquí el escenario de toma de decisiones es el siguiente:

  1. ASUMIR PÉRDIDAS ECONÓMICAS. Si la carga de esfuerzo estaba mal valorada, y nos hemos quedado muy cortos, una de las opciones que tenemos es asumir de nuestro beneficio esas desviaciones. Si una empresa por sistema empieza a asumir este tipo de riesgos, tarde o temprano quiebra. La suerte no es eterna.
  2. AÑADIR UN MARGEN DE RIESGO. En nuestro caso añadimos un porcentaje en concepto de “Riesgo” en función de tres parámetros:
    1. Claridad de las especificaciones. Si las especificaciones no están bien definidas, no son claras o no se tiene clara la funcionalidad, al final esta funcionalidad tiende a crecer (por norma general).
    2. Conocimiento Tecnologíco. Si controlamos mucho las tareas que nos encomiendan, el riesgo estará más controlado por la propia experiencia. No no sabemos nada de la tecnología que se impone en el proyecto, el riesgo se dispara.
    3. El propio cliente. Hay clientes con los que es más fácil trabajar que con otros. En este apartado son muchos los factores que influyen, grado de indecisión, velocidad de respuesta ante la toma de decisiones, experiencia previa del cliente… incluso el propio feeling que tengamos con él.
  3. NEGOCIAR LA FUNCIONALIDAD. Si la carga de esfuerzo ha crecido o discrepa entre lo que se entendió que había que hacer y lo que realmente hay que hacer, una buena opción será negociar con el cliente, o se cambia el alcance de lo que hay que hacer, se reducen o simplifican las tareas, se elimina lo menos importante… o… se amplia el presupuesto.
    Por experiencia, solo con clientes con experiencia previa y que estén contentos con los resultados que se han obtenido hasta el momento aceptan este cambio de paradigma. Pueden acogerse al presupuesto (no olvidemos que actúa como contrato y puede exigirse legalmente su cumplimiento) con lo que la negociación ha acabado y empiezan los problemas de verdad.
  4. SOLUCIONES CREATIVAS, que por lo general no suelen funcionar, como incrementar el plazo pero no el esfuerzo, dedicándole periodos muertos en los que otros proyectos se paren (muy pocos clientes aceptan esto).
  5. BAJADA DE CALIDAD. No lo toméis como una solución al problema, es siempre un problema en sí, tarde o temprano, esa deuda tecnológica, vuelve y nos hace perder más tiempo y más dinero, además de la reputación con el cliente. Por desgracia, no sabemos muy por qué ni como, en cuanto te descuidas, alguien propone la bajada de la calidad como una solución al problema.
  6. ESCLAVIZAR AL EQUIPO. Aunque parezca una solución en un principio (al menos para la empresa), al final es un verdadero problema. Todo lo que no sea justo, no se puede considerar como una solución. No es justo que el equipo sea quien asuma el error de planificación, o el error de valoración (por eso también es importante que sea el propio equipo de desarrollo el que valore el trabajo). No lo deberíamos plantear ni siquiera en condiciones excepcionales, aunque por desgracia es “el pan nuestro de cada día de los autónomos”.
  7. REVUELTO DE TODO LO ANTERIOR. Por lo general es lo que tendemos a hacer, aplicarlo todo para atenuar el problema y con un poco de suerte, solucionarlo medianamente bien.

Excepto la Negociación de funcionalidad, el resto no deberían ni estar en esta lista, pero mi experiencia te dice que cuando empiezas a estar desesperado, en algún momento, las consideras.

Si las cosas pintan así de mal…

¿Seguimos con el proyecto o nos retiramos?

Esta es la pregunta que nos deberíamos hacer, aunque nos parezca que no tenemos estas dos opciones. Cuanto detectemos que corremos riesgo, menor será las consecuencias, para la empresa (para ti) y para el cliente.

NOS RETIRAMOS. Parece lo menos malo, perdemos el tiempo que le hayamos dedicado hasta el momento y nuestra reputación hasta ese cliente. De seguir con el proyecto, perderemos mucho más tiempo, lesionaremos al equipo porque el proyecto pasará a estado “proyecto marrón” y sea como sea, perderemos la buena reputación con ese cliente y alguno más con el que hablen.

DECIDIMOS SEGUIR. Por lo general asumiremos pérdidas económicas, sobrecargaremos a los equipo (con lo que otros proyectos se pueden contagiar y verse afectados por el cansancio acumulado) y terminaremos por bajar la calidad (o asumiremos más pérdidas aun). Además, los clientes no suelen entender muy bien que más esfuerzo, requiere de más plazo de ejecución. Así que además de sobreesforzarte y perder dinero, en cuanto empiezan los retrasos empiezas a perder reputación y se enturbia la relación. Esta situación te empeora:

  1. El rendimiento económico de la empresa
  2. La relación con tus equipos de trabajo
  3. La relación con proveedores externos
  4. Muy probablemente… la pérdida de reputación con ese cliente y con todos los demás que hable.
  5. un importante coste de oportunidad, es decir, si le dedicas tu tiempo a proyecto que te perjudicará, no se lo estás dedicando a otro que te podría beneficiar.

CONCLUSIÓN.

Si no hacemos un buen presupuesto, corremos un alto riesgo de perder dinero, tiempo y muy probablemente al cliente.

Si le dedicamos tiempo y hacemos un buen trabajo de presupuestación desde el principio, asumimos el riesgo de perder el tiempo desde el principio.

Ninguno de los dos escenarios son ideales, pero sin duda me gusta mucho más el segundo.

¿Cómo lo hacéis vosotros?

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR