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

Las 35 horas semanales franceses dan para más que los 40 españoles. He observado en caso de consultoras clientes y proveedores que programadores, managers y analistas hacen horas extra, se quedan hasta las tantas, sin embargo los proyectos no experimentan boosts de rendimiento ni avances significativos. Observada esta tendencia desde hace años las empresas consultoras han introducido un sistema de registro de horas que les permitiría conocer en qué invierten sus efectivos estas preciosas horas laborables durante el día. Al principio las iniciativas de registro de horas, ledger o nombres similares parecían una forma de control y lo son pero no es su único objetivo. Además de poder saber horas reales invertidas por proyecto versus horas estimadas, llevar acabo contabilidad de costes u optimizar el uso de recursos, es una herramienta inestimable incluso para los que la tienen que cumplimentar todos los días. Teniendo un todo list integrado en herramientas de registro permite a los miembros de equipo del proyecto hacer tangible su propio trabajo y eso para el PM le facilita la contabilidad de valor acumulado del proyecto y tareas de reporting. Las herramientas sin metodología adecuada no sirven para nada, sin embargo, conociendo las herramientas adecuadas para empresas medianas y pequeñas el aprender a usarlas puede forzar la implantación de ciertos conceptos metodológicos. Las siguientes herramientas pueden ser un buen punto de partida:

• 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.

Recibidos los requerimientos del proyecto de un cliente procedemos a validarlos y realizar la estimación del esfuerzo. Después de varios días de reuniones, realización de WBS y la preparación de un PP detallado enviamos la propuesta al cliente. Pasan varios días, semanas y el cliente no da señales de vida. De repente contesta y facilita requerimientos adicionales y pide volver a estimar el proyecto. El equipo vuelve a reunirse, se validan las nuevas premisas y su implicación sobre la línea base marcada. Project Plan actualizado, la propuesta modificada y enviada al cliente. Pasan varias semanas, el cliente contesta informando de que les parece bien la propuesta sin embargo han realizado varios cambios y necesitan que se actualice la estimación, alcance y en fin la propuesta. ¿Fue correcto el comportamiento del project manager en la primera instancia cuando el cliente solicitó actualización? "Sí" y "No", "Sí" en caso de que la decisión fue tomada con criterio comercial, sin embargo "No" desde el punto de vista de la gestión. En mi opinión lo correcto sería fijarle con el cliente un marco básico de alcance y en base a la estimación aceptada desarrollar las modificaciones en formato Change Requests que deberían ser estimados de forma independiente del core de proyecto. Asimismo favoreceríamos la claridad, modularidad del proyecto así como la gestión.

En la empresa los proyectos generan entregables o documentación que debe ser archivada de una forma específica y uniforme a fin de que el personal familiarizado con la estructura pueda recuperar datos precisos en un momento dado con sencillez. Si la empresa tiene un certificado ISO 9001:2000 o CMMI entonces sus procedimientos ya contemplan la ubicación centralizada, segura y correctamente gestionada, donde se almacenan los entregables, sean documentos de proyectos, planes, blueprints, código fuente, logs de conversaciones etc. Aunque los proyectos pueden ser bastante diferentes, si hablamos de una empresa IT o de desarrollo de software, entonces debe ser capaz de unificar la estructura de datos y metadatos de sus registros de proyectos. A continuación propongo una forma de organizar y clasificar los registros que debería satisfacer los requerimientos de un rango amplio de empresas de software:

• Registros Producto
  • Base de Datos
    • Esquema
    • Scripts iniciales
    • Scripts actualización
  • Manuales
  • Fuentes
    • Código fuente genérico
    • Paquete instalación binario
    • Instrucciones
  • Informes de Pruebas
  • Modelado UML
  • User Interface
    • Wireframe
    • Screenshots
    • Prototipos
• Registros Proyecto
  • Análisis funcional
  • Documentación requerimientos
    • Casos de Uso
    • Arquitectura
  • - Contratos
    • Propuestas
    • Presupuestos
    • Pedidos
    • Aceptaciones
    • SOW’s
  • Planes de Proyecto
  • Riesgos
  • Actas
  • Informes

Lógicamente cada empresa debe personalizar esta lista a fin de ajustarla a sus necesidades.

Quería dedicar este post al contenido genérico del SOW. Cierto es que según industria el documento se formula de diferentes formas sin embargo creo que existen unos ciertos criterios comunes para crear un documento SOW bien atado. Está claro que no pretendemos hacer un documento blindado desde el punto de vista legal, en eso os podrían ayudar los servicios jurídicos de vuestra empresa. Es preferible si usamos MS Word prepararnos una plantilla genérica dónde usaremos campos para que en el caso de tener que reutilizar el documento podamos fácilmente localizar aquellos puntos importantes rápidamente para cambiarlos. Por ejemplo en la documentación uso campos para atributos Nombre Cliente, Razón Social, CIF, Dirección, Número de Horas Neto, etc. Cada SOW igual que otros documentos de proyectos deberían llevar una tabla de gestión de cambios, dónde cada vez que se modifique se incluyera una nueva versión y el nombre de la persona encargada del cambio.

• Términos Generales – Sumario de participantes cliente(s)/proveedor(es) y referencias al acuerdo marco (si existe).
  • Fechas inicio/fin y validez documento.
  • Sumario de alcance
• Contactos - Definición de stakeholders más importantes del proyecto.
  • Contactos del Cliente – PM Cliente(s) y Sponsor.
  • Contactos del Proveedor – PM Proveedor(es) y Sponsor.
• Ubicación - Definición exacta del lugar de prestación de servicio (onsite, offshore, etc.).
• Sumario Términos Comerciales - Definición del término y plazo de pago.
• Firmas - Firmas de los respectivos firmantes autorizados.
• Anexo - En esta parte del documento se detallarán la mayoría de los puntos anteriores.
  • Objetivos del Proyecto – Detalle de objetivos proyecto desde principales a secundarios.
  • Hitos ó Milestones por Fase – Cada fase debe definir la fecha del milestone junto con la descripción del producto a entregar en esta fecha.
  • Entregables – Detalle de entregables por cada milestone (ficheros, documentación, cd’s, planos, instrucciones, etc.).
    • Diccionario de entregables – Explicar que significa cada uno de los entregables.
  • Recursos - Listado de personal/perfiles y su número junto con la descripción del perfil de personas participantes en el proyecto.
  • Horas y Duración – Detalle de horas por cada fase y duración de las mismas.
  • Cláusulas especiales – En algunos casos es imprescindible definir clausulas particulares para proyectos.
    • Colaboración - Si dependemos del cliente o cualquier otro stakeholder deberemos limitar nuestra responsabilidad.
    • Gestión de cambios – Política de gestión de cambios.
    • Mantenimiento posterior – Delimitaremos el ciclo de vida del producto y separaremos su desarrollo del mantenimiento, dejando claro que el mantenimiento post-garantía es un proyecto distinto.
    • Otras.
  • Garantía - Periodo de garantía para el producto y los cambios realizados
  • Inversión - Costos por hora, hora extra, fines de semana, costes totales y por fase.
  • Reembolso y Gastos – Acuerdo sobre términos de autorización y reembolso de gastos.
  • Calendario y Pagos – Porcentajes e importes según fechas/hitos/entregables.

Comentarios:

• Los SOW’s deben hacer referencia a la documentación de fondo.
• Es buena idea incluir o acompañar el SOW con un Project Plan detallado cuyos datos coinciden con los incluidos en el sow.
• El SOW debe ser revisado por servicios jurídicos de la empresa y por el PMO en todo caso.

El documento Statement of Work (Orden de Trabajo) normalmente se prepara por los clientes enviándolo al proveedor para que éste tenga en un solo documento definido el alcance del trabajo, sin embargo puede que este acercamiento no sea el más adecuado para la mayoría de ocasiones, con grandes e incluso medianas empresas. La preparación de documentación todavía no se considera como parte integral del proceso sino un "mal" con el que hay que lidiar. Pedirles a clientes que ya te han hecho un "favor" de considerarte posible proveedor que prepare un documento administrativo puede ser a veces mucho pedir es por ello ellos – los clientes buscan proveedores que les quiten los problemas no añadan nuevas. Por eso, si el proveedor tiene una mayor madurez de proceso que el cliente será necesario contemplar que la preparación de documentos debe ser llevada acabo por los propios consultores o project managers, de esta forma nos aseguraremos de que el cliente no se quema, ni tampoco se le olvida algo importante a la hora de formular el SOW o cualquier otro documento de proyecto.

Continuará…

Trabajando con distintos proveedores y clientes a veces nos llegan muchas iniciativas que podrían convertirse proyectos sin embargo un gran volumen de los mismos no llega a prosperar por distintas razones. Para evitar quemarse y agotar a nuestros proveedores el Project Manager selecciona los proyectos que más interesan a la empresa y también se encarga de elaborar la documentación inicial para que los proveedores sean internos o externos (desarrolladores) puedan estimar. Si cada vez les pedimos que inviertan un tiempo considerable en la estimación definitiva nos vamos a encontrar de que se invierten muchas horas para esfuerzos que quizás no compensen. Por ejemplo proveedores pueden quemarse de tanto estimar y no ganar proyectos. La solución podría ser en aplicar la técnica de rolling wave (moving window) en la estimación, elaborar primero un ROM estimate o Budget Estimate y mostrarlo al cliente. Si no se "asusta" y da el visto bueno preliminar proceder con Definitive Estimate en formato MS Project. Al tenerlo se lo proporcionamos con esperanza de que lo aprueben. Al aprobarlo procederemos a preparar un documentos SOW correspondientes.

Continuará…

El Cafe de Joe es un blog dedicado a Gestión de Proyectos y es una iniciativa de Irwin J. Franco PMP a.k.a. "Joe" desde Guayaquil – Ecuador. Joe es un miembro del PMI, corresponsal de PM World Today y trabaja como Project Manager en Image Tech. En su blog sigue activamente la actualidad de gestión de proyectos y publica artículos interesantes sobre la metodología, temática relacionada con proyectos y tecnología. El Cafe de Joe siguiendo con las actividades del Día Internacional del Project Management recientemente ha publicado varias entrevistas. Quería agradecerle a Joe que me haya considerado para una de ellas. A continuación pueden leer la entrevista completa aquí.

Aparte de las dificultades habituales de cualquier proyecto y bajo un inocente velo de transparencia, a veces el equipo de gestión se empeña en trasladar a los miembros del equipo de producción (desarrollo, fabricación, construcción, etc.) toda la información de la que dispone a medida de que le va llegando lo que puede crear en los participantes preocupaciones innecesarias, si los datos no se distribuyen de forma adecuada. Transparencia como política de gestión, sin ninguna duda, es algo positivo pero introduzcamos una variable más – la llamada "need to know". Un criterio para decidir quién debe saber qué y para qué. En los equipos cada uno sabe exactamente el labor que le corresponde (o por lo menos debería). Es el rol de del Project Manager y sus asociados decidir a quién se le debe proporcionar la información, de qué manera y con qué fin. Es allí Donde entra en el juego la matriz de comunicaciones, un documento "vivo" que muestra cómo debería fluir la información en el proyecto. Complicaciones a nivel político, quejas, comentarios de clientes o proveedores deben ser previamente evaluados y dirigidos de forma controlada a los que necesitan y pueden actuar en beneficio del proyecto al disponer de la información.

Las iniciativas que requieren participación de un cierto número de personas sea en local o distribuidos geográficamente necesitan que estos grupos desarrollen un sentimiento de pertenencia al grupo y comprendan exactamente el objetivo del proyecto y los entregables a producir. Para esta tarea desde hace algunos años, al principio sólo en el sector de construcción e ingeniería, se utilizaban war-rooms, centros de guerra (traducción libre), dónde los participantes tenían a su plena disposición y fácil accesibilidad toda la documentación del proyecto a la vista. Allí se reunían, discutían y pensaban sobre como resolver los problemas, y también celebraban el éxito. Para proyectos de software el warroom debería tener posteado en la pared los diagramas WBS y el PERT, en sus últimas 2 versiones para ver los cambios que se realizaron. Para facilitar el entendimiento el WBS dictionarry también debería figurar allí mismo. Es buena idea postear el registro de riesgos con sus planes de mitigación y contingencia. Ese espacio dedicado al proyecto no es fácil de mantener si tenemos equipos distribuidos por todo el mundo por lo que disponibilidad de una intranet con los mismos datos en formato Wiki puede ser una válida alternativa.