Utiliza las Declaraciones de Alcance del Proyecto para Salvar el Día (con Robyn Birkedal)

Lee la transcripción:

Estamos probando la transcripción de nuestros pódcast con un software. Por favor, perdona cualquier error ya que el bot no es 100% preciso.

Ben Aston:

Estás nervioso, temblando y con la frente sudando. El cliente está enfadado. Está al teléfono amenazando con cancelar el proyecto y no pagar el trabajo. Y hasta ahora, todo había ido tan bien. Ellos estaban totalmente relajados y tú también. Querían rediseñar su sitio web. Sonaba sencillo. Y realmente no te molestaste en escribir nada porque, bueno, sentías que todos lo entendían. Todos estaban tranquilos y ahora ya no lo están. Lo que realmente pensaban que recibirían era un rebranding además de ese rediseño web. Ahora tienes el estómago hecho un nudo porque sabes que metiste la pata. No quedaba nada escrito. Y es su palabra contra la tuya. Ahora me estreso de solo contarlo. Así que si quieres mucho menos estrés, sigue escuchando este pódcast para descubrir por qué las declaraciones de Alcance son tan importantes. Cómo redactarlas y usarlas en tu proyecto.

Gracias por acompañarnos. Soy Ben Aston, fundador de The Digital Project Manager. Bienvenido al pódcast de DPM. Tenemos la misión de ayudar a los gestores de proyecto a triunfar, a ayudar a quienes gestionan proyectos a entregarlos mejor. Estamos aquí para que lleves tu práctica de gestión de proyectos al próximo nivel. Visita thedigitalprojectmanager.com para conocer nuestra formación y recursos disponibles a través de una membresía. Este pódcast es patrocinado por Clarizen, el líder en software de gestión de cartera y proyectos empresariales. Visita Clarizen.com para saber más.

Hoy nos acompaña Robyn. Robyn es una de nuestras expertas en DPM residentes. Y, casualmente, vive a la vuelta de la esquina, de donde vivo yo. He leído recientemente que le gustan los emojis, hacer listas y los cachorros. Así que es una chef convertida en gestora de proyectos con más de 10 años de experiencia en agencias y startups. Y de hecho está a punto de estar más disponible para encargos de contratación. Así que si buscas un PM freelance, búscala en LinkedIn. Pero, Robyn, muchas gracias por estar hoy con nosotros.

Robyn Birkedal:

Hola Ben. Siempre es un placer estar contigo.

Ben Aston:

Quisiera empezar hablando de eso de hacer listas y de los cachorros. ¿Has hecho la lista hoy?

Robyn Birkedal:

Sí, de hecho, soy una completa nerd. Tengo una lista para los objetivos principales de hoy. Tengo otra en mi agenda. Y luego también tengo mi Google Calendar. Así que aparentemente necesito tres listas diferentes a la vez. Y lo que no ves detrás de mí es mi “muro del crimen” lleno de notas adhesivas.

Ben Aston:

Eso es como el archivo histórico de tus listas.

Robyn Birkedal:

Cosas en diferentes categorías que intento conseguir, tanto a nivel personal como profesional, o incluso ideas de contenido para ti.

Ben Aston:

¿Tienes algún cachorro contigo?

Robyn Birkedal:

Sí, tengo mi cachorro de ocho años. Pero obviamente, me gustan mucho más los perros que los gatos, y cualquiera me puede criticar por eso. Con los emojis últimamente no estoy tan entusiasmada. Pero creo que fue solo una fase.

Ben Aston:

Eso era muy de, el año pasado.

Robyn Birkedal:

No sé

Ben Aston:

Obviamente hacer listas es importante para ti. Algunos las encuentran inspiradoras. Pero tengo curiosidad por saber, ¿qué te inspira a ti últimamente? ¿Qué estás leyendo? ¿Qué consumes ahora que te inspira?

Robyn Birkedal:

Gran pregunta. Podría hablar treinta minutos solo de eso ahora mismo. Por supuesto, The Digital Project Manager es una fuente constante de inspiración. Hice una pequeña pausa en mi participación en la comunidad de Slack, y ahora que he vuelto, he echado mucho de menos a mis amigos ahí. Eso ha sido una alegría, además de mi círculo local y mi comunidad. Pero también quiero mencionar un grupo genial de Portland, PDXWIT, que es Portland Women in Technology. Y aprecio mucho esa comunidad, que ha organizado muy bien eventos de capacitación, mentoría y acceso a empleos. Me han enseñado sobre diversidad e inclusión. Así que os animo a crear algo similar o visitarlas en pdxwit.org.

Ben Aston:

Muy bien. ¿Y en qué intentas mejorar ahora? Todos tenemos algo más de tiempo. Cada vez veo más cosas tipo masterclass, fitness y demás. Pero, ¿qué te inspira ahora? ¿Estás trabajando algún nuevo hobby? ¿Aprendiendo algún lenguaje de programación nuevo? ¿En qué andas ahora?

Robyn Birkedal:

Bueno, últimamente no he trabajado con Drupal en siete años, así que ando poniéndome al día. Pero, fuera de eso, Ben, tú lo sabes, esto es casi un secreto: estoy pensando en sacarme nuevas certificaciones, como la PMP o algo de metodologías ágiles como SAFe, aún tengo que ver cuál. Pero explorar si quiero avanzar más en esas metodologías y no solo seguir en la zona de confort.

Ben Aston:

Muy bien, ¡ánimo con eso! ¿Algo más que hayas descubierto últimamente que te haga la vida más feliz? Ahora son las pequeñas cosas las que dan alegría.

Robyn Birkedal:

Esto es un poco vergonzoso, no sé por qué estoy tan nerviosa hoy, pero disfruto mucho trabajar desde casa y de fondo pongo un canal en YouTube TV, tengo suscripción, que es todo surf. Y viviendo en Portland, me toma hora y media llegar a la playa, no surfeo ni sé sobre surf, pero ver el canal Ambient Surf TV Championship me fascina. Ahora soy fan de Andy Irons y del escándalo de Kelly Slater. Aprendí mucho, es la última rareza que me hace feliz.

Ben Aston:

¿Quién es tu surfista favorito?

Robyn Birkedal:

Sin duda, Kelly Slater.

Ben Aston:

Eso es. Es un buen punto de partida. Mi pequeña fama es que surfeé una vez con Kelly Slater en Hawái.

Robyn Birkedal:

Eso no se puede decir así nomás.

Ben Aston:

Estábamos saliendo del agua y él entraba con su novia. Cruzamos y le dije, hola Kelly. Así que técnicamente, surfeé con él.

Robyn Birkedal:

Sí, estabas en el agua al mismo tiempo.

Ben Aston:

Sí, algo así.

Robyn Birkedal:

Entonces sí estuviste en las grandes olas, si estabas ahí con Kelly.

Ben Aston:

Sí, es mi pequeño mérito. Bueno, vamos al tema serio, dejando la playa, hablemos de las declaraciones de alcance. Empecemos por el porqué. Yo intenté ponerlo en contexto al principio: por qué importan las declaraciones de alcance. Los proyectos fallan, hay malos entendidos, y las declaraciones de alcance pueden salvarnos. ¿Tienes alguna historia de terror por no tener declaración de alcance?

Robyn Birkedal:

Absolutamente. Incluso escuchando tu introducción, me vino ese trauma. Las declaraciones de alcance son súper importantes porque garantizan que tu equipo y el cliente tengan claro lo que se requiere. Definen cómo vas a fracasar y qué pasaría. Lo que intentamos proteger aquí es no abrirnos a conflictos con el cliente, el equipo interno y también alinear a todos y, si se puede, evitar pleitos.

Ben Aston:

Intentamos aclarar y unificar la comprensión lo más posible, y creo que la clave de las declaraciones de alcance es codificar ese entendimiento. A veces pensamos que estamos en la misma página, que somos amigos, pero de hecho cuando hay amistad es peor, porque todos asumen que entienden lo mismo. Y luego hay palabras como “actualizar” o “refrescar” que son ambiguas, pero las declaraciones de alcance eliminan esa ambigüedad y lo dejan claro.

Robyn Birkedal:

Totalmente. Incluso en estos 10 años que llevo trabajando, esas palabras cambian hasta cada trimestre. Y antes de hablar de qué son y cómo hacerlas, quiero compartir que escribir una declaración de alcance está poco valorado en esta profesión. Es la parte más árida del trabajo y normalmente la más difícil al iniciar un proyecto. A nadie le gusta asumirla. Es tu tarea. Pero personalmente, me encanta porque, bueno, soy media nerd, pero dedicar ese tiempo al principio asegura un futuro eficiente para el proyecto.

Ben Aston:

Definitivamente. Así que, en lo más básico, para quien no sepa, ¿qué es una declaración de alcance?

Robyn Birkedal:

Existen muchos términos diferentes, como mencionaste, Ben, sobre “refrescar” o “rediseñar”. ¿Y cómo se diferencian de la SOW? Según entiendo, una declaración de alcance es una manera de describir el trabajo que has acordado entregar. Expone, en lo más fundamental, las limitaciones y restricciones del proyecto. Es decir, qué se va a entregar, qué no, suposiciones sobre lo que se entregará y cualquier otra aclaración.

Ben Aston:

Entonces, la declaración de alcance sí, la usamos para describir el trabajo a realizar, definir y codificar el alcance. Decimos, esto es lo que vamos a hacer, esto es lo que no. Y a veces, si no podemos definirlo, describimos el proceso. Algunas personas preguntan si necesitan una SOW o cómo se ve una SOW ágil. Seguimos necesitando definir lo que hacemos y lo que no. Pero en vez de definir los entregables, podemos enfocarnos en el resultado o el proceso para alcanzarlo.

Robyn Birkedal:

Sí, para complementar. Hay algunos básicos que debes seguir. Hablaremos de consejos, pero no hay una sola plantilla estándar que sigan todos los gestores de proyectos digitales. Cada negocio es diferente. Cada programa o proyecto es diferente. Lo que buscamos es coherencia para cubrir tus espaldas, o como puse en el artículo, “salvar tu pellejo”. Porque tienes que proteger a tu equipo y la iniciativa del negocio.

Ben Aston:

Sí. ¿Tienes alguna historia de no definir bien la declaración de alcance y qué sucedió?

Robyn Birkedal:

Es complicado porque en proyectos pasados me aconsejaban no poner mucho detalle para no exponerte a litigios. Si pones mucho, pueden aprovecharse de las zonas grises. Pero donde más éxito he tenido es poniendo todo el detalle posible, ya sea método cascada o ágil. Define todo lo que sabes en esa declaración y verifica con el cliente. Ya tendremos tiempo para más historias de terror, pero por experiencia, a veces no lo haces perfecto y el cliente lo ve diferente. Se trata de navegar esa situación y dedicar tiempo al principio. Todos tenemos historias peores.

Ben Aston:

Sí. Mi historia más terrorífica: trabajamos con una gran empresa de electrónica y debíamos crear unas animaciones personalizadas. El cliente quería que compráramos los derechos de la animación y lo hicimos: una licencia de 5 años, suficiente porque solo era para una campaña. Pensamos: bueno, 5 años por si se reutiliza, aunque en realidad solo hacía falta un año. Más adelante el cliente dice: “Oye, os pedí derechos”. Nosotros: “Sí, los tenemos”. Cliente: “Pero los necesitamos a perpetuidad, en cualquier medio, para siempre”. Y solo compramos 5 años. El estudio de animación lo sabía y pudo cobrar lo que quisiera. Así que trataron de aprovecharlo. Al final, la relación con el cliente se vino abajo por este malentendido en una declaración de alcance poco clara sobre la duración de los derechos. Pequeñas cosas así pueden tener enormes consecuencias y generar conflictos simplemente porque pueden. Así que hay que tomarlas en serio.

Hablemos sobre cómo escribir estas declaraciones de alcance y el proceso que sigues. ¿Cómo decides cómo redactarlas? Puedes dejar abierto a interpretación, o puedes ser súper detallado y cubrir todos los escenarios.

Robyn Birkedal:

Antes de nada, tres cosas: uno, no soy abogada. Solo hablo desde mi experiencia en publicidad. Segundo, insisto, no soy abogada. Tercero, siento lo de tu caso, Ben. A veces los términos “a perpetuidad” y “cinco años” son muy distintos, es una lección dolorosa. Volviendo al tema, en nuestro entorno las declaraciones de alcance pueden ser estimaciones, SOW, contratos, propuestas… un conjunto que adopta varios formatos. Algunos nombres que he usado: acuerdos de servicio, contratos, propuestas, pero ojo, no son NDA, MSA, ICA o SLA (más sobre eso en mi artículo). No es lo único que debes dar al cliente, solo una parte.

Ben Aston:

Claro.

Robyn Birkedal:

Sobre cómo las hago: suelo usar plantillas de mi equipo interno. Suerte de haber trabajado en sitios con buenas plantillas. También guardo versiones de SOW pasadas en una carpeta personal para ver cómo resolví otros proyectos: branding, digital, refresh, etc. Obviamente, The Digital Project Manager es gran recurso y sé que tienes un artículo excelente sobre cómo escribir una SOW con plantilla. Así que puedes inspirarte allí también.

Ben Aston:

Totalmente. Tener tu propio banco de declaraciones de alcance que puedas reducir, reutilizar y reciclar es clave. Si haces regularmente el mismo tipo de entregables, el proceso es similar y puedes reciclarlas fácilmente.

En el sitio, si no lo has visto, visita thedigitalprojectmanager.com/project-scope-statement y verás muchas declaraciones de alcance que tenemos. Algunas son genéricas, puedes reciclarlas en tus proyectos y solo cambiar los nombres. Otras más específicas requieren más personalización. Así que haz un banco de declaraciones de alcance. Algunas siempre serán personalizadas, pero otras pueden reciclarse, por ejemplo, quién paga licencias de imágenes, derechos de vídeo, plazos de revisión o el número de rondas de aprobaciones.

Vamos a hablar de declaraciones de alcance buenas y malas. Hay una especie de continuo: desde declaraciones poco específicas hasta muy detalladas. No es necesariamente mejor ni peor, pero ¿qué hace una buena o mala declaración de alcance?

Robyn Birkedal:

Vaya, es una gran pregunta. Podríamos hablar de eso durante horas. Me gusta lo que decías: apóyate en tu banco de declaraciones anteriores, pide a colegas o amigos recursos efectivos, así no empiezas desde cero. Te puedo dar cinco consejos para salvar tu pellejo. ¿Quieres escucharlos?

Ben Aston:

Sí, adelante.

Robyn Birkedal:

Desde mi experiencia, encuentro útil: uno, define el porqué, suelo llamarlo “visión general”. Es la primera sección que define por qué existe el proyecto o programa, qué logrará. Todos hemos escrito “introducciones” en ensayos de jóvenes; esto es lo mismo, pero aplicado como adultos. A veces delego esto a la figura del gestor de cuentas para que obtenga los KPIs del cliente. No es necesario narrar todo, mantenlo breve y claro; sirve para enmarcar todo el trabajo y justificarlo después.

Ben Aston:

Sí, empezar por el porqué es súper importante, porque si todo lo demás falla, esto es nuestro seguro. Si puedes demostrar que lo entregado cumple esa finalidad, aunque el cliente no esté encantado con la ejecución, tienes un terreno común. Si tu objetivo era aumentar suscriptores y demuestras que lo lograste, eso es un respaldo importante.

Robyn Birkedal:

Claro. Y eso sirve en cualquier metodología de proyectos. Es bueno ponerlo al principio en Slack o documentación del equipo. Lo principal es alinear a todos. El segundo consejo es delimitar el proceso de aprobación. Parece básico, pero ahí suelen surgir problemas.

Recomiendo redactar al menos lenguaje básico que detalle cómo se aprueban los entregables: ¿cuándo el cliente debe dar feedback?, ¿quién lo dará?, ¿cómo debe enviarse? Puedes empezar de forma básica y expandirlo antes de avanzar. Ben y yo hemos tenido muchos dolores de cabeza aquí. Es bueno hablarlo verbalmente con el cliente y luego dejarlo por escrito.

Ben Aston:

Totalmente. Buen consejo.

Robyn Birkedal:

El tercer consejo: identifica claramente lo que vas a entregar. Suele ser lo más extenso. Puede ser súper detallado (cascada) o más enfocado en proceso (ágil). Lista qué va a recibir la gente, cuándo y cómo. Soy muy detallista; para mí son clave las rondas de revisión, entrada por contrato, migración, hosting, configuración, QA formal, derechos de imagen y el despliegue.

Ben Aston:

Yo pienso igual: si puedes definirlo, hazlo y limita el alcance. Si no sabes cuántos entregables serán, recomiendo la técnica “sandbag”, es decir, aseguras lo mínimo que seguro entregarás. Si crees que puedes hacer cuatro conceptos, di que harás dos y cumple con esos, porque puede que al final solo se hagan dos. O si crees que construirás hasta cinco componentes, acuerda cinco y no sobre comprometas. Así puedes sorprender positivamente después. Si dices siete y son cinco, el cliente puede pedir compensación.

Robyn Birkedal:

Totalmente, me ha pasado. Esto también ayuda a controlar lo interno: el equipo puede tener desacuerdos con la carga de trabajo, así que al identificar esto en la fase de descubrimiento, mitigamos conflictos, internamente y con el cliente. El cuarto consejo: define qué está incluido y qué no. Normalmente va en una sección aparte tras los entregables. Aquí hago lista exhaustiva para cubrir lo que sé y lo que no. Lo llamo “límites”. Primero, marco dependencias y suposiciones, donde aclaras quién da feedback, quién tiene la relación y también cosas como si hay varios despliegues o se pospone alguno habrá orden de cambio y requiere más recursos. En mi artículo listo ejemplos. Después, me gusta la sección llamada “exclusiones” o “fuera de alcance”. Todo lo que el cliente podría pedir y no está incluido, como derechos de imagen a perpetuidad, formación, hosting, documentación, guías de estilo digitales, etc. Todo lo que creas que se puede pedir y no lo provees, déjalo claro.

Ben Aston:

Sí, o puede que incluso sí se haya hablado pero igual surgen malos entendidos. A esto lo llaman también “declaraciones de alcance negativo”. Explica todo lo que definitivamente no harás. Por ejemplo, puede que el cliente quiera rebranding, pero no hay presupuesto. Así que hay que incluir específicamente que no se hará rebranding en este proyecto. Piensa en todas esas ideas locas que surgieron en las reuniones y déjalas claras como fuera de alcance.

Robyn Birkedal:

Me encanta eso. No hay solo una forma correcta; se trata de fiarte de tu instinto y anotar los posibles problemas. Algunos jefes me han dicho que exagero o soy catastrofista, así que resumir ayuda, pero eso es lo que hacemos: prever riesgos desde el principio. El quinto y último consejo, algo controvertido quizá, me gusta hacer una matriz de alcance. Esto lo aprendí hace años. Antes perdía horas revisando versiones de documentos, mails, mensajes, archivos de diseño, hasta código, para saber exactamente qué se dijo. He aprendido que al entregar la declaración de alcance, puedo llevar un control de entregables desde el principio y ahorrar dolores de cabeza después.

Ben Aston:

La idea es que, como los entregables pueden cambiar, la SOW se mantenga como documento vivo. Poner los entregables en una matriz permite registrar avances y recordar al cliente que este documento se toma en serio y es usado. Es una buena manera de mantener la conversación y el control.

Robyn Birkedal:

Exacto. Y Ben, a veces ni comparto esa matriz con el cliente, la dejo interna en los archivos del proyecto. Pero la saco si surge conflicto, así tengo todos los recursos listos y no pierdo horas en el pasado.

Ben Aston:

¡Suena fácil! Si sigues estos consejos, todo sale bien… ¿o no? Cuéntame, ¿cuáles son los mayores desafíos, dónde suelen fallar las declaraciones de alcance?

Robyn Birkedal:

Donde suele fallar es que no hay que seguir las “reglas” ciegamente, sino ser flexible y abordar cada proyecto individualmente. Antes intentaba seguir solo la plantilla y aprendí que hay que adaptarse, los clientes son distintos y requieren enfoques distintos. Así que ahora soy más flexible, pero también más estricta en lo que realmente se acuerda realizar.

Ben Aston:

Sí, uno de los grandes retos es definir cuán detallada debe ser la declaración al inicio. A veces puedes sobrepasarte: piensas que desde el principio vas a entregar X, Y y Z, y después de investigar o diseñar te das cuenta de que Z no es necesario, posible o asequible.

Así que es buena idea pensar en tu “horizonte de planificación”. Escribe declaraciones de alcance realistas para cada fase, no te adelantes. Si vas a la fase de descubrimiento, limita el alcance a esa fase y luego, como parte de esa fase, defines el alcance de la siguiente etapa, ya sea diseño, desarrollo, etc. El mayor riesgo es “adelantarse” y asumir que sabes todo cuando en realidad no es así.

Robyn Birkedal:

Sí. Otro desafío es lograr la firma de la declaración de alcance por parte del cliente, pero sin haber involucrado a todos los stakeholders. Eso sí puede acabar perjudicando el proyecto. Es esencial hacer una revisión verbal y asegurar el alineamiento en persona.

Ben Aston:

Claro. Es importante esa revisión verbal porque no quieres que el cliente firme sin leer o sin entender de verdad lo que firmó. Queremos asegurarnos de que el cliente entiende a qué se compromete; no queremos que la declaración sea solo legal. Queremos que sirva para alinear expectativas. No queremos que termine en juicio o con abogados interpretando lo que significa el documento. Si llegamos ahí, todos pierden. El objetivo es alinearnos, que todos estén satisfechos con el resultado y la forma en que se llevó el proyecto. Ese es mi gran aprendizaje de hoy.

Robyn Birkedal:

Totalmente. No hay nada más satisfactorio que poder copiar-pegar la declaración de alcance en un documento legal y saber que todos están alineados: cliente y equipo.

Ben Aston:

¡Eso es! Gracias, Robyn, por acompañarnos hoy. Ha sido genial tenerte.

Robyn Birkedal:

Gracias a vosotros.

Ben Aston:

Y para quienes nos escuchan, me gustaría saber: ¿Cuáles son vuestros trucos y consejos para declaraciones de alcance o SOW? ¿Dónde las guardas, cómo las produces, qué funciona y qué no? Cuéntanos tus historias de fracaso y de éxito en los comentarios. Si quieres aprender más y avanzar en tu carrera, únete a nuestra tribu de miembros de DPM en thedigitaprojectmanager.com/membership para acceder a nuestro Slack, mentorías, plantillas, talleres, sesiones AMA, e-books y más. Y si lo que has escuchado hoy te ha gustado, por favor suscríbete y sigue en contacto en thedigitalprojectmanager.com. Hasta la próxima. Muchas gracias por escuchar.