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.

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

Nos llega por correo del jefe o directamente del cliente una petición de estimar un proyecto basándose en un fichero adjunto. Ese es el escenario más común a partir del cual empiezan nuestras peripecias para responder al requerimiento usando ¿sólo? la información proporcionada… Según el alcance y el detalle de información incluida en la documentación de requerimientos podemos utilizar una o varias técnicas de estimación de proyectos. Imaginemos que con suerte el documento anexo es un análisis funcional con casos de uso de la aplicación (escenario óptimo), en este caso hemos tenido suerte ya que según el esmero del personal técnico y el nivel de insistencia podemos usar cualquiera de las técnicas más comunes de estimación (FP – Puntos Funcionales, UCP – Puntos de Casos de Uso, EDT/WBS – Bottom up, etc.). Pero no siempre es así, suelen llegar documentos poco detallados y ambiguos que no permiten estimación cerrada fiable. Para estos casos se puede todavía aplicar estimaciones por puntos funcionales (FP), lógicamente no obtendremos estimaciones fiables cerradas. Es nuestro deber informarle al cliente o al sponsor, o alternativamente intentar solicitar aclaraciones y más detalles. Desde el punto de vista de precisión de la estimación tenemos siguientes tipos:

• Estimación de Orden de Magnitud (ROM) Precisión -25% +50/75%
• Budget Precisión -15% +30%
• Definitiva (cerrada) Precisión -5% +15%

Continuará…

La WBS también llamada en español EDT (Estructura de Descomposición del Trabajo) puede ser organizada estructuralmente de diferentes maneras. La forma más lógica IMHO es hacerlo es empezar con datos de programa, proyectos, fases, agrupaciones de cuentas de control y a continuación paquetes de trabajo hasta representar todo el trabajo y solo el trabajo necesario para conseguir el objetivo del proyecto/programa. Por ejemplo si tenemos un proyecto con el fin de realizar un estudio de viabilidad la plantilla de WBS o Gantt en MS Project podría ser la siguiente:

• [Código de Proyecto] {Sumario Breve} (Versión "x") <– Nivel 1 – Sumario proyecto/programa
  • Preparación <– Nivel 2 – Fase – Tareas preliminares necesarias para poder empezar la siguiente fase.
    • Paquete de trabajo 1 <– Nivel 3 – Paquete de trabajo.
    • …
  • Ejecución <– Nivel 2 – Fase – Tareas de la fase de ejecución o desarrollo.
    • …
  • Project Management <– Nivel 2 – Fase – Tareas de gestión de proyecto y de configuración.
    • …
  • Reservas y Buffers <– Nivel 2 – Agrupación de cuentas de control necesarias para uso de TOC (Theory of Constraints de Goldratt).
    • …
  • Hitos <– Nivel 2 – Hitos del proyecto agrupados

Advanced companies normally have guidelines for overall project management methodology, flexible enough to allow PM’s tailor specific process application and the level of rigor. Teams that have adopted management by projects in their core usually follow these logical steps of "should we do it", "can we do it" which lead to the charter creation by an external manager; while companies that do projects for clients usually do not feel the need of doing so as this preliminary research supposedly had already been made by the client. From my experience very few of them really follow these steps, I’d say some 30% but of course it depends on the industry and geographical location. Functional Specifications are built upon Scope Statement and they should not be documented by the PM but by a specialized analyst knowledgeable about Use-Case analysis (not only software industry). IT Project Management industry in Spain: 1) Charters – < 3-4% 2) Formal ROI – > 60% 3) SOW – 40% 4) Functional Spec – 80%