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.

Ya tenemos el MPP con la información de nuestro equipo. Este "pool de recursos" ya puede ser accedido desde otros ficheros MS Project. El archivo MPP con datos de nuestro equipo debe estar disponible a través de la red ya que los ficheros de planes de proyecto A, B y C necesitarán acceder a los datos que contiene. Si estamos en una red local, el pool puede ser publicado en una carpeta compartida con permisos de lectura y escritura. Según los datos anteriores ya podemos crear planes de proyecto a través de MS Project Professional para cada una de nuestras iniciativas. Al tener todas las tareas introducidas y sequenciadas en lugar de añadir equipo al plan en sí debemos pedirle al MS Project que use los recursos compartidos del pool. Eso se hace desde el menú "Tools" – "Resources Sharing" – "Share Resources". Y en la caja "Share Resources" y marcamos la opción "Use Resources". Es importante saber que los dos ficheros deben estar abiertos – el Plan y el Pool.

Continuará…

En caso de disponer de MS Project Server, a través de su funcionalidad de pool de recursos ofrece toda la información necesaria para nivelar la involucración de personal en proyectos por defecto. En la segunda entrega de la serie "Gestión de conjuntos de proyectos – programas" me refería al uso de la aplicación MS Project Professional, sin usar MS Project Server. Vamos a examinar paso a paso como conseguir controlar un programa de proyectos con ficheros MPP. Para el escenario consideraremos un programa con 3 proyectos A, B y C. Tenemos un equipo de 5 trabajadores: Antonio, Ana, Juan, Juliana y Pepe. Así pues tendremos 1 archivo MPP con los datos de nuestros recursos. Este fichero será considerado como pool de recursos, allí añadiremos los nombres, departamentos, funciones, precios por hora normales, costos extra u otros datos adicionales del personal. Si estamos en un entorno con Active Directory o LDAP podremos importar estos datos a MS Project. Cuando hayamos terminados de añadir los datos de recursos debemos convertir el MPP típico en un fichero ‘resource pool’. Se hace desde el menu "Tools" (Herramientas) – "Resource Sharing" (Recursos compartidos) en el menu "Share Resources" (Compartir recursos) con opción "Use own resources" (Usar recursos propios).

Continuará…