Declaración de trabajo. Por muy sencillo que parezca, hacerla bien no es tarea fácil. Pero nada es más fundamental para el éxito de un proyecto. Si la declaración de trabajo es demasiado vaga, demasiado amplia o demasiado genérica, puede dejar lugar a varias interpretaciones, lo que puede dar lugar a problemas en el futuro. Eso es cierto para un proyecto interno, y es doblemente cierto cuando hay proveedores involucrados.
«La falta de ejecución adecuada de una declaración de trabajo es a menudo la razón por la que las partes terminan en una disputa», dice David M. Greenberg, un abogado en el grupo de práctica de tecnología, medios de comunicación y telecomunicaciones en la oficina de Greenberg Traurig LLP ‘s Nueva York.
Para que su proyecto salga bien a la primera, siga estas pautas para redactar una declaración de trabajo eficaz, o SOW, como se le llama cariñosamente.
Entender qué es un SOW.
Un SOW define el alcance del trabajo requerido y el tiempo en el que se debe realizar. Es «la piedra angular de un acuerdo», dice Nick Scafidi, director de compras de TI en el proveedor de energía National Grid USA en Westboro, Massachusetts. «Establece las expectativas, los resultados, lo que es aceptable, el precio y el calendario de precios. Sin eso, es como decirle a un contratista: ‘Constrúyeme una casa’, diciéndole cuándo, de qué tipo o de qué tamaño».
Saber qué incluir.
Bruce Russell, que firmó numerosos SOWs cuando era director de operaciones en una empresa de desarrollo de software, dice que uno bueno incluye estas cosas:
- Los principales entregables y cuándo se esperan.
- Las tareas que apoyan los entregables, así como qué parte -la empresa contratante o el proveedor de servicios- realizará esas tareas.
- El proceso de gobernanza del proyecto, junto con la frecuencia con la que se reunirán los comités de gobierno.
- Qué recursos se necesitan para el proyecto, qué instalaciones se utilizarán y qué equipos se necesitarán, así como los requisitos de las pruebas.
- Quién pagará qué costes y cuándo.
«La declaración de trabajo reúne todos los elementos al principio», dice Russell, ahora profesor ejecutivo en la Escuela de Negocios de la Universidad Northeastern de Boston. «Y cuanto más precisa sea, más cuantitativa, mejor».
Defina el éxito.
Una declaración de trabajo debe aclarar a todas las partes lo que constituye el éxito o el fracaso, dice Melise R. Blakeslee, abogada del grupo de propiedad intelectual, medios de comunicación y transacciones tecnológicas de McDermott Will & Emery LLP en Washington.
«Hay que describir adecuadamente en qué consiste el trabajo y los criterios para que ambos estén de acuerdo» en que algo se ha completado con éxito, dice Ruth Anne Guerrero, directora de normas del Project Management Institute Inc. en Newtown Square, Pensilvania, y antigua directora de proyectos de TI.
Por ejemplo, si espera que su proveedor desarrolle los requisitos de los usuarios, su SOW debería establecer que el proveedor debe entrevistar a grupos específicos de usuarios y hacer que éstos aprueben los requisitos antes de que el trabajo se considere terminado. Eso define mejor el éxito que decir simplemente: «El proveedor elaborará los requisitos del usuario».
La definición de éxito depende del proyecto, dice Guerrero. Los líderes de proyectos de TI deben especificar si la implementación exitosa se define por la velocidad, el tiempo de respuesta, la facilidad de uso o las tres cosas, y luego cuantificarlas en el SOW.
No olvide un calendario.
Sin embargo, las implementaciones exitosas no pueden definirse sólo por la velocidad o la capacidad de respuesta del sistema. Después de todo, ¿de qué sirve una gran aplicación si se tarda una década en construirla? Por eso un SOW debe incluir elementos de tiempo. Guerrero recomienda utilizar un lenguaje que permita cierta flexibilidad en lugar de una fecha fija en el calendario. Un SOW debería especificar, por ejemplo, que los requisitos del usuario final deben estar listos dos meses después de la firma del contrato, una redacción que hace que el proyecto siga avanzando al tiempo que da cabida a posibles problemas como un retraso en la firma del contrato.
Un SOW también debe designar momentos específicos para las revisiones formales, de modo que todas las partes implicadas puedan confirmar que van por buen camino, dice Matt Liberatore, profesor del departamento de tecnologías de la decisión y la información y de la cátedra John F. Connelly de gestión de la Facultad de Comercio y Finanzas de la Universidad de Villanova, en Villanova, Pensilvania.
Emparejar el pago a los hitos.
Otro componente clave para mantener el trabajo en marcha es establecer hitos específicos en el SOW y vincular el pago a la finalización con éxito, dice Blakeslee.
Cuando Scafidi redacta un SOW, especifica que los pagos a los proveedores se realizan tras la aceptación de los productos clave. También señala que retendrá una parte del pago hasta que el proveedor demuestre que todos los entregables funcionan juntos.
Usa un lenguaje que todos puedan entender.
El departamento de TI y sus proveedores no son los únicos que utilizan el SOW, dice Blakeslee. Así que no lo escriba como si sólo lo viera el personal de TI. «Debe ser comprensible para los usuarios finales, los proveedores de servicios, la dirección y un juez», dice.
Sea específico.
Aunque numerosas partes tienen que entender la declaración de trabajo, sea preciso al describir el alcance y los requisitos del proyecto, dice Blakeslee. Ha visto documentos que establecen objetivos vagos, como «trabajarán lo mejor posible». Lo compara con un propietario que contrata a un pintor con instrucciones de «hacer el mejor esfuerzo posible».
«Si el pintor hace eso pero pinta su casa de color morado en lugar de blanco, entonces no tendría una reclamación contra él», dice.
Scafidi se ha tomado a pecho este consejo. En lugar de decir que una tarea llevará «una cantidad razonable de tiempo», Scafidi escribe: «La tarea especificada no llevará más de cuatro horas.»
«Los abogados se sienten bien cuando tenemos una definición clara e inequívoca en cosas así», dice.
Recuerda las necesidades de postproducción.
Guerrero recomienda incluir los requisitos de postproducción en el SOW. Detalla las pruebas y el apoyo que necesitará del proveedor, dice. Y si piensa contar con personal interno para dar soporte al sistema después de la instalación, el SOW debe indicar si el proveedor formará a su personal. Este lenguaje, dice, garantiza que el proveedor no «simplemente entrega el sistema y se va».
Pratt es escritora colaboradora de Computerworld en Waltham, Mass. Contacte con ella en [email protected].