Cuando nuestras facturas emitidas así como las recibidas reflejan toda la información tal como a nosotros nos gusta, lo seguro es que se nos olvida algo y pronto lo echaremos de menos. Es normal, con lo que habrá que estar atento y en el momento de observar alguna necesidad realizar ajustes pertinentes en el sistema de facturación. Los datos que contienen las facturas contienen la información fundamental sobre la cual podemos construir nuestro análisis para tener mayor visibilidad sobre los costes netos, overheads, gastos, beneficios, pagos a terceros – en otras palabras el cashflow para un conjunto de proyectos. En mi trabajo necesito tener los siguientes datos para poder gestionar de forma eficiente un Project Management Office que gestiona proyectos, programas y portfolios.

• Márgenes por:
  • a) Proyecto
  • b) Proveedor
  • c) Perfil técnico
  • d) Tecnología
• Facturación por:
  • a) Proveedor
  • b) Cliente y OU Cliente
  • c) Proyecto
  • d) Área de Proyectos (logística, defensa, etc.)
  • e) Project Manager

Todos estos datos representados de forma gráfica y cruzada nos permiten determinar que proyectos son más lucrativos que otros, quienes son nuestros mejores clientes y proveedores, proyectos en qué tecnología nos generan mayores rendimientos.

Continuará…

Tener las facturas de proveedores bien registradas es un buen comienzo y una fundación sólida para medir la eficacia de nuestro trabajo y poder analizar con fiabilidad los datos económicos de cada proyecto y así llegar a tener una imagen clara de la situación total de los programas y finalmente de la empresa en sí. Las facturas de Clientes quizá sean aun más importantes que las de proveedores, ya a los últimos se les puede exigir un determinado comportamiento, mientras que los clientes nos exigen a nosotros, los proveedores que actuemos de una u otra manera para ajustarse a su forma de ser. De todas formas, se les pueden plantear o sugerir determinadas acciones, proporcionando en la medida de lo posible una justificación o mejor dicho explicación del porqué de los entresijos del proceso administrativo.

Facturas a Clientes

• Normalmente en términos generales las condiciones de cobro con los clientes deben ser mejores que las condiciones de pago a proveedores, en otras palabras permitirnos seguir el clásico "cobrar antes y pagar tarde".
• Las facturas a clientes deben tener las mismas exactamente líneas que las facturas de proveedores, por lo que los conceptos deben ser compatibles, aparte…incluiremos conceptos adicionales de trabajos realizados internamente. Esta distinción en un futuro clarificará qué partida de trabajo corresponde al proveedor, su margen (comparación), y trabajo realizado internamente.
• Una factura a un cliente no puede tener líneas que no correspondan a proyectos distintos.
• Las facturas a clientes aparte de tener todos los requisitos exigibles legalmente deben contener los siguientes datos: los códigos de cliente, proyecto, pedido, partner (en caso de ser referido), datos sobre el hito o concepto concreto al que se refiere la factura.
• A fin de asegurar un pago correcto el staff PMO debe ponerse en contacto con el cliente y acordar una pre-aprobación de factura a través del envío de ésta en formato PDF. Recibida la confirmación se deberá proceder a emitir la factura oficial, haciéndosela llegar con mayor brevedad posible al cliente.
• Todas las facturas a clientes deben tener una cláusula de penalización por retraso en el pago, haciendo referencia la cláusula de penalización en el SOW.

Continuará…

A fin de poder realizar un seguimiento pormenorizado de costes a nivel de proyecto así como a nivel de empresa debemos registrar las horas en base a ciertos conceptos de contabilidad de coste (Activity Based Costing). Aunque realmente el ABC no se suele hacer a nivel de pyme algunas ideas de esta contabilidad pueden y deben ser aplicados para poder hacer un seguimiento coste-beneficio de un proyecto o portfolio de proyectos. Las siguientes ideas me facilitan el trabajo por lo que las propongo aquí:

Facturas de Proveedores

• Una factura no debe tener líneas correspondientes a otros proyectos. Y para ser más obsesivo todavía una factura debe tener una sola línea, aunque no parezca importante este hecho facilitará el trabajo no solo a los contables sino a nosotros mismos a la hora de cruzar los ingresos con los gastos.
• El concepto en la factura debe ser claramente definido, indicando: los códigos del cliente, proyecto, pedido, partner (en caso de ser referido), datos sobre el hito o concepto concreto al que se refiere la factura, el número de horas totales vs. número de horas facturadas en la factura, precio por hora (estándar o normalizado en caso de que un proyecto implique uso de recursos de diferente coste), importes (neto y descuentos/penalizaciones por separado).
• El número de factura debe ser muy visible así como la fecha factura y vencimiento.
• El documento de factura debe incluir un texto legal sobre retrasos de pago y penalizaciones así como bonificaciones por pronto pago (si es aplicable).
• Las facturas antes de recibirse deben ser enviados por correo electrónico en formato PDF al Project Manager para ser revisadas y pre-aprobadas…, después al dpto de contabilidad para su pago.
• Los responsables de contabilidad y cobros deberían tener un listado detallado sobre el estado de cobro de la factura – aging report a fin de que los project managers puedan hacer el seguimiento.
• Debe existir en el listado anterior por cada factura la fecha de primera emisión, validación por confirming, fecha aceptación cliente, fecha envío, fecha pago.
• Es importante que el staff contable del proyecto aparte de realizar el seguimiento a nivel de factura también tenga visibilidad de movimientos de fondos en las cuentas de empresa correspondientes al proyecto desde donde se cobra y se paga a clientes y proveedores del proyecto.
• Teniendo en cuenta que normalmente recibiríamos facturas de proveedores después de que enviemos facturas a clientes éstas deberían incluir una referencia a la factura enviada al cliente, una reseña, que más adelante nos permitirá casar fácilmente las facturas emitidas con facturas recibidas.

Continuará…

¿En qué consiste una estimación del proyecto? Cada vez que un cliente solicita un presupuesto en esta acostumbrado o mejor dicho habituado a recibir un presupuesto según determinados criterios implícitamente claros para él. Para que el presupuesto no juegue con una desventaja innecesaria, preguntamos al cliente el formato en el que desea recibir el presupuesto. Tratándose del gobierno, nos lo indicarían en el pliego, pero si tratamos con empresas medianas o pequeñas debemos intentar de forma explicita solicitar esta información a fin de que el cliente tenga facilidades para leerlo. En aquellos casos cuando esta info adicional no esta disponible recomiendo facilitarle al cliente la estimación de forma escalonada, salvo que hayan instrucciones en contra. La estimación ocupa tiempo y recursos, para intentar asegurarse de que cuando lo preparemos y se lo enviaremos no se asusta, primero sería prudente facilitarle un orden de magnitud, como si avisáramos sobre el alcance. Si vemos que la reacción es favorable, pues a continuación tranquilamente podemos dedicarnos a realizar una estimación bottom-up. Este paso previo sirve como hemos visto para reducir un poco el riesgo. Para facilitarle un presupuesto al cliente sobre un proyecto, sería adecuado el formato de MS Project o cualquier otra alternativa que permita plasmar de forma gráfica las tareas, costes, duración, dependencias entre las tareas, etc. Un WBS con un diccionario WBS de alto nivel para explicar en que consiste cada una de las tareas. El último documento permite entender al cliente el contenido de paquetes de trabajo. Y cuando el cliente se pronuncie favorablemente sobre nuestra estimación en MS Project podemos concluir esta fase del proyecto formalizando un Statement of Work, dónde se definen claramente las condiciones comerciales, alcance, fechas, embediendo el presupuesto en MS Project original.

Continuando con el tema de estimaciones de proyecto, tenemos un escenario donde se nos ha facilitado un documento breve que describe en términos generales el alcance del proyecto. El documento contiene suficiente información para poder preparar estimaciones de tipo ROM o en mejor de los casos Budget, sin embargo el cliente desea que nos comprometamos con un precio cerrado. En estos casos debemos barajar siguientes variables:

1. Background y conocimiento del Cliente
2. Plazo para proporcionar la estimación
3. Importancia proyecto (volumen de negocio, cliente, etc.)
4. Riesgo vs. volumen información proporcionada.
5. Relación que existe con el cliente y confianza.

Consideremos diferentes escenarios:

• Worst Case Scenario. El cliente tiene pocos conocimientos técnicos y su background no permite elaborar documentación como casos de uso o análisis funcional para correcta estimación del proyecto. El cliente tiene mucha prisa y solicita un presupuesto "ya". Es un cliente nuevo y no tenemos una relación de confianza establecida.
  • Evaluando la importancia del proyecto y cliente para la empresa el PMO únicamente puede preparar estimaciones ROM y Budget, pero será la decisión de la dirección comercial de la empresa si desea adquirir un compromiso con el cliente, considerando una de nuestras estimaciones como fija.
  • El cliente no busca soluciones alternativas sino una estimación y nada más, la otra opción que nos quedaría es ser transparentes e informarles que con el volumen de requerimientos que tenemos no podemos abordar el proyecto en condiciones de seguridad o riesgo conocido.

• Best Case Scenario. El cliente aunque no tenga conocimientos técnicos y preparación para crear el documento por sí entiende la complicación de la preparación de una estimación fija ya que no desea otro tipo de ofertas, sin embargo dispone de tiempo para ayudar a la empresa a preparar la documentación de requerimientos con suficiente detalle. En este caso se podría ofrecerle romper el proyecto en 2 fases:
  • En la primera fase se realizaría un trabajo onsite en instalaciones del cliente, recogiendo toda la información necesaria para preparar unos casos de uso en condiciones. Este documento podrá ser usado por cualquier otra empresa de gestión de proyectos o empresa desarrolladora de software. Se puede formalizar este trabajo de consultoría con contrato de tipo "time and material" o "precio fijo" (incluyendo desplazamientos, consultoría y etc.).
  • En la segunda fase con la documentación de casos de uso preparada se puede realizar una estimación fija. Normalmente si en la primera fase la empresa se muestra profesional, el cliente suele confiar en su criterio. En este caso el cliente si lo desea puede tener contrato de tipo firm fixed price FFP – precio fijo.

Continuará…

Nuestro proyecto ha sido aprobado bajo términos Cost Plus Incentive Fee (CPIF), un tipo de contrato muy poco utilizado en España pero bastante en Estados Unidos, especialmente cuando se trabaja con la defensa. En nuestro caso se ha definido que si llegamos a realizar el proyecto con el coste de $300.000, nos podemos llevar el 10% como puro beneficio. Pero si conseguimos entregar por debajo de este coste el ratio 80/20 será aplicado, de forma que todo lo que se ahorre el 80% es puro ahorro para el comprador y el 20% es el incentivo del vendedor. El coste real del proyecto ha sido $275.000, por lo que debemos calcular el coste real que supone para el cliente a fin de saber lo que nos debe pagar. La forma de calcularlo es la siguiente: