Decidiste subcontratar una parte del trabajo a una empresa.  El trabajo del proveedor implica instalación de cajas de aluminio donde se engancharían la electrónica del sistema.

Después de un par de ciclos observas que el reporting de estado que proporciona el proveedor no refleja correctamente la situación actual del esfuerzo.

¿Cuándo podemos lanzar una auditoría independiente para confirmar nuestra sospecha? ¿Cómo debemos abordar esta situación?

En el proceso de Administración de Contrato primero se debió haber definido como requisito la posibilidad de auditar sus procesos, a continuación detectada la sospecha de ineficiencia durante el proceso de Realizar Aseguramiento de Calidad solicitamos en una reunión la petición de auditoría.

Habitualmente habrá que negociar la métrica de rendimiento, un benchmark. Si la auditoría independiente muestra que el rendimiento es peor que el benchmark el coste correría a  cuenta del proveedor, asimismo abriría la puerta a posibles penalizaciones si se incurre en retrasos. Por el contrario si el benchmark es superado, nosotros deberíamos financiar la auditoría y realizar un ajuste en el sistema de medición de eficacia parte de nuestro proceso de Aseguramiento de Calidad. 

Al concedércele un nuevo proyecto al Project Manager, éste se encuentra con un dilema – ¿a quién pedir recursos para el proyecto? 

La resolución de este dilema tiene facetas burocráticas y políticas, es decir, por un lado preparar una Estructura de Descomposición de Recursos (RBS) y Plan de Recursos y por el otro negociar su disponibilidad e involucración con sus line managers y otros Jefes de Proyecto, respetando el complejo entramado de dependencias políticas que puedan existir.

La RBS principalmente sirve para hacernos una idea clara de qué tipo de recursos necesitamos y qué departamentos nos los pueden facilitar, mientras que el Plan de Recursos nos dará todos los datos reales de recursos para que podamos asignar por cada tarea a personas específicas encargadas de llevarla a cabo. 

Teniendo claro el alcance del proyecto y cuales son los paquetes de trabajo (EDT), podemos ir creando una lista de recursos genéricos (Analistas, Consultores, DBA, etc) que agruparemos por departamentos (Programación, Consultoría, Tratamiento de Datos, etc.). Dentro del plan de proyecto a cada tarea le asignamos uno o varios recursos genéricos lo que ofrecerá una visión inicial del esfuerzo, plazos, así como nos da una idea aproximada sobre el número de recursos por perfil que podamos necesitar (en función de sobreasignación).

Con el RBS y el Plan de Proyecto se conciertan entrevistas con Line Managers para llegar a compromisos de dedicación.

Alcanzados estos compromisos, tenemos nombres de recursos, fechas de disponibilidad, sus horarios, ubicaciones, costes asociados (desplazamientos, costos por uso, etc.) y también conocemos su número. Al sustituir los recursos genéricos por reales obtenemos un plan de proyecto real, con su camino crítico, recurso tambor en función del cual nos deberemos organizar y fechas. 

Proyectos grandes requieren que cada uno de estos pasos genere documentos formales, sin embargo en caso de esfuerzos medianos tener un Microsoft Project Plan con asignación de recursos y revisado con Line Managers sería suficiente.

Una de las primeras cosas es hacer que el cliente ya no hablo de tu propia empresa entiendan cuál es tu rol en el proyecto. Algunos, no especialmente familiarizados con el concepto de gestión pueden erróneamente atribuirte tareas que no te corresponden, generando así expectativas que seguro que no podrás cumplir.

Una llamada al Cliente, sus contactos técnicos y/o de gestión, claro está si no tienes un project manager al otro lado puede evitar muchas decepciones.

Una buena agenda para esta llamada podría ser:

• Explicar tu Rol en el proyecto
• Habla sobre tu propio background y experiencia en la Gestión de Proyectos
• Habla sobre la función de jefe de Proyecto (9 Áreas de Gestión de proyecto)
  • Integración – Cumplimiento de Metodología e integración del resto de áreas de conocimientos.
  • Alcance - Planificación de proyecto desde perspectiva de alcance (lo que se va a hacer y lo que no se va a hacer en el proyecto)
  • Tiempo - Control de línea de tiempo, entregas, entregables y plazos.
  • Coste - Control de línea de costes, valor acumulado, etc.
  • Calidad - Control y aseguramiento de calidad en todo el proceso interno y externo del proyecto.
  • Recursos Humanos - Organización y distribución de trabajo para todo el equipo de desarrollo (menciona el número de personas involucradas).
  • Comunicación – Gestión de expectativas, reporting, vamos el 90% de tu tiempo.
  • Riesgos – Gestión de los riesgos, calificación y diseño de planes de contingencia y estrategias de mitigación.
  • Aprovisionamiento y adquisiciones - Aprovisionamiento y gestión de infraestructura necesaria para el proyecto. Compras y Gestión de contratos, etc.

Toda la charla es difícil de tragar y asimilar, así pues para terminar resume tus objetivos. Por ejemplo: Mi propósito es asegurarme de que el proyecto se entrega según el alcance definido, dentro de las limitaciones de coste y en plazo.

A continuación sería conveniente ofrecerle al cliente la oportunidad de preguntar por si tiene alguna duda que puedes aprovechar para reforzar tu mensaje inicial.

Luego si lo/la ves receptivo deja claro los siguientes puntos:

• Todo lo que tiene que ver con la gestión del proyecto (tiempo, alcance, coste, recursos, logística) es necesario tratar con el PM ya que si cualquiera de los aspectos de esta triple restricción (alcance, tiempos y coste) cambia afecta a las demás.
• Si cualquiera de los aspectos de esta triple restricción (alcance, tiempos y coste) cambia yo debo estar informado y autorizar y controlarlo.

Espero que la llamada vaya bien y que el cliente cuelgue con una clara idea de lo que un PM es, qué puede hacer y para qué sirve.

El “poder duro”, asociado normalmente con la agresividad, a través de medidas de coerción, ejercicio de fuerza y amenaza de castigo, es un término clave en muchas de las teorías de realismo político y estrategias de negociación en proyectos. Teorías históricamente relevantes al concepto de poder ya que enfatizan la codicia de algunos negociadores de conseguir la situación de ganancia, dominación, sin considerar siquiera la posibilidad de llegar a un win-win. Esta vía de lograr los objetivos requiere fuerza física, acceso a recursos y a medida de que los interlocutores evolucionan en su conocimiento y experiencia, rara vez resulta eficaz a largo plazo y puede suscitar una respuesta inesperada (e.g.: rotura de negociaciones y situaciones lose-lose). Sin embargo, existen situaciones cuando el uso de “poder duro” es la única vía para alcanzar el objetivo.

Mientras que el “poder blando”, un instrumento igualmente afilado en manos de un project manager apto, sirve para conseguir los mismos objetivos pero mediante diálogo, convencimiento, negociación e incluso manipulación. El empleo provechoso de poder blando depende de otras restricciones, tales como capacidad de comunicación, carisma personal, credibilidad y autoridad aunque a veces puede confundirse con debilidad. El “poder blando” difícil de utilizar per se, a diferencia del “poder duro” muy pocas veces resulta suficiente, salvo excepciones. Una forma efectiva de conseguir nuestros objetivos políticos en el proyecto es combinar las características comunes y las diferencias de ambas técnicas coactivas vistiendo "la mano de hierro” con “un guante de terciopelo”.

El reto de los managers de hoy es saber medir la cantidad de ambos ingredientes y combinarlos para conseguir el “poder inteligente”, menos invasivo, menos dependiente de recursos y más diplomático. Para concluir, los dos tipos de poder son simples medios para conseguir un fin, los dos pueden ser igualmente poco humanitarios y utilizados de forma independiente su eficacia a veces es limitada. Cada uno de los poderes tiene sus propias características únicas y limitaciones: el “poder duro” es intensivo en uso de recursos, perseverancia, requiere fuerza física y se materializa a través de agresión; el “poder blando”, a su vez más difícil de usar, precisa dones de comunicación, carisma personal, credibilidad y diplomacia entre otras cualidades.

Referencias:

• Joseph S. Nye Jr., 2008, “El próximo líder estadounidense” (PDF), Project Syndicate.
• Jack Donnelly, 2000, “Realism and International Relations”, Cambridge University Press.
• Joseph S. Nye Jr., 2004, “Misuses of Power: Causes and Corrections”, Compass: A Journal of Leadership.
• Alexander Moseley, 2006, “Political Realism – The Internet Encyclopedia of Philosophy”, URL.
• Joseph S. Nye Jr., 2006, “Soft Power Is Cultural Power”, Foreign Policy, 1 March 2006.

• 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á…

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á…

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á…

• Achievo (http://www.achievo.org) – Registro de horas y timesheet, buena madurez, open source.
• Replicon Timesheet (http://www.replicon.com/) – Registro de horas, timesheet, gastos, buena madurez, software comercial.
• Journyx Timesheet (http://www.journyx.com/) – Idem, software comercial, pero tiene versión limitada a 10 usuarios gratuita.

Feedback bienvenido.