Cómo Construir y Escalar Equipos de Gestión de Proyectos (con Brian Kessman de Lodestar Digital)

Lee la transcripción:

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

Ben Aston:

Gracias por sintonizar. Soy Ben Aston y este es el pódcast de gestión digital de proyectos. Hoy me acompaña Brian Kessman y vamos a hablar sobre el artículo que acaba de escribir para nosotros acerca de cómo construir y escalar equipos de gestión de proyectos digitales dentro de una agencia. Pero antes de hablar de tu artículo, Bryan, ¿puedes contarnos un poco sobre ti?

Brian Kessman:

Sí, claro, primero gracias por invitarme al pódcast y por la invitación para escribir el artículo, lo disfruté mucho. Yo radico en Chapel Hill, Carolina del Norte, originalmente soy de Nueva York, crecí en Long Island y viví algunos años en Manhattan, pero ahora vivimos aquí y actualmente dirijo una firma de consultoría, Lodestar Digital, y eso es a lo que me dedico.

Ben Aston:

Genial, cuéntanos un poco sobre Lodestar, ¿a qué se dedica Lodestar?

Brian Kessman:

Claro. Lodestar es un grupo de consultoría. Su objetivo es ayudar a agencias digitales y creativas a construir y mejorar sus servicios digitales, lo que en mi trabajo implica ayudar a agencias con cambios en la estructura organizacional o de equipos, todo con el fin de ofrecer un mejor trabajo digital. Crear quizás nuevas disciplinas digitales, como la gestión de proyectos digitales, escalar o agilizar flujos de trabajo. A veces es también implementar prácticas ágiles, pero más bien una versión modificada para el entorno creativo. Esas son las categorías de servicios principales.

Ben Aston:

Entonces ahora haces consultoría en esta área, ¿cómo fue que comenzaste en la gestión de proyectos digitales y ayudas a agencias en esto? ¿Cuál es tu historial?

Brian Kessman:

Empecé en la gestión de proyectos hace años cuando hacía consultoría tecnológica y, después de eso, trabajé en el mundo de la publicidad. Tomé un tiempo para consultoría tecnológica y ahí fue donde aprendí sobre la gestión de proyectos. Pero cuando volví al sector de agencias pude aplicar esas habilidades. Durante los últimos diecisiete o dieciocho años, he trabajado mayormente en agencias digitales o en roles digitales dentro de agencias tradicionales.

Ese es el alcance de mi experiencia, pero en los últimos diez años me he centrado en mejorar procesos y entregas en agencias, desarrollo web y de apps, y he visto sobre todo dolores de crecimiento. Las agencias con las que trabajé eran pequeñas o medianas, y al crecer observaba patrones similares a los que ya había resuelto en otros lugares, así que decidí ayudar a agencias con esos mismos problemas porque el trabajo digital se incrementa y muchas agencias aún batallan con ello, ya sea del lado creativo, para hacer digital por primera vez o expandirlo, o agencias digitales creciendo y necesitando mejorar.

Ben Aston:

Bien, entonces ayudas a agencias tradicionales a volverse digitales y escalar. ¿Cuáles son los desafíos típicos que encuentras en eso? ¿Cuáles son los problemas habituales? Seguro que se identifican muchos de nuestros oyentes.

Brian Kessman:

Sí, claro, en general el principal obstáculo en una agencia creativa es el enfoque en silos de disciplinas, donde aún se trabaja de manera aislada y se pasa el trabajo al siguiente grupo, y aunque ya no es tan fuerte como antes, sigue ocurriendo, sobre todo en agencias tradicionales grandes. Lo que ofrezco es el modelo de equipo multidisciplinario cruzado, en el que estos equipos, sean fijos o temporales, trabajan juntos, hay más transparencia y mejor comprensión de los roles de los demás. Esto eleva la conciencia digital y las competencias.

Por ejemplo, puede que un diseñador trabaje en el diseño de un sitio web pero no tenga enfoque digital y no considere un diseño adaptable. Cuando lo pasa al desarrollador, hay que rehacer mucho porque no tuvo en cuenta ciertos aspectos.

Ben Aston:

Sí, eso es muy común. Es esa situación clásica cuando alguien nunca ha hecho un diseño web y utiliza dimensiones muy raras o esquemas no pensados para web. Ese tipo de detalles se suelen olvidar.

Brian Kessman:

O como cuando entregan el diseño de una valla publicitaria pero no consideran la landing page a la que lleva la publicidad.

Ben Aston:

Claro, convertir la valla en una landing page. Solo hay que ponerle un botón, ¿no? Genial. Entonces, hablando sobre la gestión digital de proyectos, tú asesoras a agencias para que mejoren. ¿Qué herramientas tienes en tu kit o has descubierto últimamente que consideres imprescindibles?

Brian Kessman:

Sí, actualmente me gusta mucho una herramienta que lanzó hace poco InVision, llamada Designbetter.co. No sé si la conoces.

Ben Aston:

No, creo que no la he visto.

Brian Kessman:

Buscan mejorar la práctica del diseño, no solo digital, sino para resolver problemas de negocio. Tienen excelentes pódcast, artículos y cursos por email con grandes líderes de diseño, y es un recurso increíble para aprender a construir grandes productos y equipos. El contenido es muy completo. Lo recomiendo muchísimo, aplicable a cualquier disciplina. Pero eso es más para educación y crecimiento. En cuanto a mis herramientas para mi trabajo de consultoría –no tanto la gestión digital directa de proyectos...

Ben Aston:

Sí.

Brian Kessman:

Dependo mucho de talleres, entrevistas, encuestas, como el mapeo de interesados, para identificar relaciones rotas dentro de la agencia. También hago mapas de procesos y análisis de brechas de habilidades, uso la matriz de habilidades de la que hablé en el artículo y cosas por el estilo.

Ben Aston:

Muy bien. Y regresando a herramientas, a todos les gustan. Cuando ayudas a las agencias a enfocarse más digitalmente o trabajar en equipo, ¿hay herramientas que faciliten el proceso y rompan los silos?

Brian Kessman:

Sí, seguro. Es cuestión de software para gestión de flujos de trabajo. Hay muchas opciones. Es la que la agencia prefiera. JIRA es excelente para desarrollo de software y muchas agencias la usan para trabajos creativos. Lo más importante es crear transparencia para el trabajo y agilizar el flujo a través de la colaboración.

Ben Aston:

Genial. Pues vamos a hablar de tu artículo, que trata sobre cómo escalar equipos de gestión de proyectos digitales y hacerlo bien. Si no lo han leído, es un gran recurso, tanto si lideras un equipo de gestión de proyectos digitales como si no, porque es una guía paso a paso. Incluso si no te aplica directamente ahora, lo que vamos a discutir es completamente útil también para llevar tus propios proyectos, porque puedes aplicar estos conceptos a otra escala. En el artículo, Brian habla de las cinco P para escalar un equipo de gestión de proyectos: propósito, personas, asociaciones, procesos y desempeño.

Propósito es reunir a los interesados para acordar por qué escalar la gestión digital de proyectos. Personas es conseguir a la gente adecuada con las habilidades y experiencia necesarias y salarios correctos. Asociaciones es estructurar el equipo internamente y que los jefes de proyecto puedan tener éxito. Proceso involucra plantillas y herramientas para ser consistentes y entregar valor. Y desempeño trata sobre monitorizar y mejorar continuamente. Eso es un resumen rápido, pero ve al artículo para más detalle.

Ahora vamos a profundizar en la primera P, el propósito, que es el motivo por el que existen los equipos de gestión de proyectos digitales. Creo que muchas veces la gente recibe el encargo de gestionar proyectos digitales en su agencia. Lo vemos mucho en el equipo de Slack: llega alguien y dice "Me acaban de dar el rol de gestión de proyectos digitales, ¿qué se supone que debo hacer?" Y muchas veces es una reacción a que algo salió mal. Piensan "estos proyectos digitales no funcionan como los otros" o "nuestros proyectos siempre se van de presupuesto, se entregan tarde; necesitamos a alguien a quien culpar, así que tú serás el DPM". Entonces, ¿qué variaciones ves en el propósito de la gestión digital de proyectos dentro de agencias?

Brian Kessman:

Creo que la variación no es tanto del propósito sino en cómo se articula. En el fondo, siempre es lo mismo, la diferencia es si alguien se toma el tiempo de definir el propósito del grupo. Como mencionas, muchos asumen el rol de DPM sin que eso esté definido y nadie sabe qué se supone que deben hacer ni reciben apoyo suficiente. Así que el propósito como tal no varía, varía el que se haya delineado explícitamente.

Ben Aston:

Y, como alguien que ha creado equipos de gestión de proyectos digitales, uno de los retos es que llegas a escalar el equipo y equilibrar el status quo —donde no había gestión digital de proyectos— con la nueva etapa con un equipo DPM, y normalmente empiezas pequeño. ¿Cómo escalar eso, cómo evitar tomar más de lo que se puede manejar y no abrumarse? ¿Qué aconsejas para esa transición?

Brian Kessman:

Todos los pasos funcionan como un sistema. Si defines bien el propósito, el siguiente paso es especialización, centrarse en cuál es el valor específico o los resultados que vas a dar en tu rol: tu especialidad. Si te enfocas en eso, no te sobrecargarás. Por ejemplo, el propósito que mencioné es producir proyectos exitosos reduciendo riesgos y problemas mediante la planificación, así que eso es lo central: enfócate en la planificación de proyectos. Siempre habrá áreas grises, pero lo importante es mantener tu especialización clara.

Ben Aston:

Genial, vayamos ahora a personas. Dices que es crítico tener a la persona adecuada liderando el equipo. ¿Cómo identificas líderes? Para quienes buscan ser elegidos para liderar una PMO, ¿qué habilidades deben desarrollar y qué características buscarías para liderar un equipo PMO?

Brian Kessman:

Es un equilibrio entre habilidades duras y blandas. Hay que tener experiencia, las "cicatrices de guerra" para ayudar en lo táctico del día a día, pero lo más importante para un rol de liderazgo son las habilidades blandas: motivar al equipo, lograr que te respeten, entender las perspectivas en cada rol y tener empatía. Una parte fundamental es el liderazgo servicial: no hacer por ellos sino ayudarles a que puedan hacer, removiendo barreras y dándoles soporte para crecer y aprender.

Ben Aston:

Totalmente de acuerdo. Describes que el líder debe dedicar al menos el 50% de su tiempo a mentoría y apoyo; para los que no lo hacen, ¿cómo es ese apoyo y mentoría en la práctica? Por ejemplo, yo revisaba reportes de estado, forecastings, estimaciones, reuniones... ¿Qué haces para ayudar a los PM más junior a mejorar?

Brian Kessman:

Es estar disponible para conversar. Si sabes escuchar, identificas áreas de desafío aún si el PM no lo percibe. Tener reuniones uno a uno, tomar un café, comer juntos mensualmente. También observar conductas en reuniones clave como kick-offs y onboarding, para después dar retroalimentación. Todo esto se relaciona con la matriz de habilidades del artículo: si defines las habilidades esperadas para cada nivel, puedes usarlas en conjunto con ejemplos y así ayudar al crecimiento estableciendo metas claras y acciones de mejora.

Ben Aston:

Justamente. Y sobre desarrollo profesional: para un gestor digital de proyectos, ¿vale la pena hacer el PMP, scrum master u otras certificaciones? ¿Qué formación hallas más útil?

Brian Kessman:

Hay dos partes: mi experiencia y la utilidad general. Cuando gestionaba proyectos, estudié para el PMP pero no hice el examen; sentí que aprendí lo necesario y que no precisaba el diploma. Sí hice la certificación de scrum master y product owner, que me pareció invaluable. Todos deberían hacerlo porque ofrece otra perspectiva para enfrentar el trabajo y es hacia donde va la industria, con adaptaciones ágiles. Más allá de eso, aprender de otras disciplinas es vital: los PMs interactúan con todos, así que conviene entender algo de diseño, desarrollo, codificación, escuchar podcasts, etc. Así colaboras y apoyas mejor.

Ben Aston:

Creo que es muy buen consejo: cuanto más comprendamos lo que hacen nuestros equipos, mejor podremos anticipar obstáculos. Tener el conocimiento para hacer preguntas adecuadas ayuda mucho a resolver problemas a tiempo.

Brian Kessman:

Cierto. Mencionaste estrategia, que es fundamental. Los PMs por lo general conocen bien diseño y desarrollo, pero pocas veces se relacionan tanto con estrategia. Si pueden acercarse a ese equipo, su perspectiva sobre proyectos mejorará, asegurando que se alineen a la estrategia de fondo.

Ben Aston:

Sí, a veces está aislado. Cuando hay un equipo de cuentas o la estrategia la lleva el director de cuentas y luego se pasa el proyecto, el PM tiene que entender el trasfondo estratégico para lograr entregar éxito. Ser estratégico permite identificar dónde recortar o mejorar en favor de los objetivos.

Sobre tu matriz de habilidades: ¿cómo decidir qué niveles de habilidad se requieren según el rol y el área? ¿Cómo defines eso para que sirva a cada agencia?

Brian Kessman:

Depende de la complejidad de proyectos y clientes. A veces sólo contratan PM seniors, pero debería ser un trabajo en equipo, no decisión del director de proyectos. Hay que discutir los tipos de proyectos, problemas y oportunidades, y definir colaborativamente lo que cada rol debe manejar. Así se promueve el crecimiento y la motivación, no la evaluación negativa.

Ben Aston:

Muy útil. En cuanto a conseguir a las personas adecuadas y contratar, ¿cómo haces para fichar a PM seniors si recursos humanos dice que no hay presupuesto? ¿Consejos para contratar dentro de un presupuesto?

Brian Kessman:

Por eso la matriz de habilidades es clave: crea entendimiento sobre lo que cada nivel de PM puede y no puede hacer. Si involucras a recursos humanos o finanzas en el desarrollo de esa matriz, puedes argumentar con fundamento por qué necesitas un perfil senior para determinado tipo de proyectos y asociar rangos salariales a cada nivel, mostrando tarifas competitivas del mercado. Así, todos entienden y anticipan el presupuesto necesario.

Esta herramienta ayuda mucho a conseguir lo que el equipo realmente necesita.

Ben Aston:

Exacto, argumentar por alguien senior o, a veces, sumar más PM juniors para dar soporte a los seniors y hacer más estratégica la labor. Ahora, la tercera P: asociaciones, es decir, relaciones dentro de la agencia. Hablas de la matriz RACI: ¿puedes explicarla y decir hasta dónde detallarla merece la pena?

Brian Kessman:

Crear una matriz RACI implica mucho trabajo y colaboración entre todas las disciplinas. La RACI representa Responsible (responsable), Accountable (responsable final), Consulted (consultado) e Informed (informado). Haces una matriz cruzando las fases y pasos principales del proceso, y quién es responsable, responsable final, consultado e informado en cada caso. Solo puede haber un accountable. El accountable asegura que el paso se haga bien; los responsables hacen el trabajo; los consultados aportan información; los informados reciben notificaciones. No hay que hacerlo demasiado detallado hasta que sea necesario, se puede construir y ajustar sobre la marcha.

Ben Aston:

Buena explicación para diferenciar roles. Cuando una agencia se vuelve digital hay quienes quieren ser consultados o informados en todo. ¿Cómo reducir la lista de consultados e informados para agilizar?

Brian Kessman:

Es un buen problema, pues demuestra pasión y compromiso, pero hay que simplificar: no debe haber veinte personas en cada reunión. Para eso, usar software de gestión de flujos ayuda: permite consultar y automatizar la información; así, los updates van por e-mail y se evita la sobrecarga de involucrar a todo el mundo en todo.

Ben Aston:

Perfecto. Pasemos a la P favorita de los PM: proceso. Hablas de estandarizar procesos, algo crítico al volverse una agencia más digital pero también cuando se gestionan múltiples tipos de proyectos. ¿Cómo estandarizas el proceso para que sea útil en distintos proyectos, y también flexible?

Brian Kessman:

Es una decisión estratégica: si la agencia se especializa en un área o vertical, puedes estandarizar mucho. Si, por ejemplo, eres una agencia de realidad aumentada para productos de hogar, tus proyectos serán similares y tu proceso muy replicable. Si no te especializas, encontrarás patrones comunes entre tus proyectos. El primer paso es categorizar y estandarizar esos patrones. Lo ideal sería especializarse, pero incluso sin hacerlo, siempre habrá elementos repetidos donde estandarizar y optimizar los procesos.

Ben Aston:

Exacto. Yo suelo tomar el tipo de proyecto más complejo y construir el estándar sobre ese, para que los más simples sean subconjuntos, así se gana eficiencia y no se pierde el control al hacer algo diferente cada vez. La estandarización ayuda mucho a evitar esfuerzos innecesarios y sobrecostes.

Diseñando para lo más complejo y luego extrayendo para los más pequeños, aseguramos eficiencia y claridad en los proyectos, evitando trabajos que no añaden valor a los entregables.

Brian Kessman:

Así es.

Ben Aston:

Por último, desempeño. ¿Cada cuánto lo revisas y cómo se mide para asegurar mejora continua?

Brian Kessman:

De nuevo, empieza pequeño: elige una o dos métricas clave (KPI), como tiempo promedio de entrega, tasa de entregas a tiempo, rentabilidad, etc. Mide y revisa periódicamente (por ejemplo, trimestralmente con encuestas internas), y así puedes fijar acciones de mejora para el siguiente período. Las encuestas a clientes también son valiosas —el Net Promoter Score mide si te recomendarían— y permiten comentarios cualitativos. Eso ayuda a mejorar tanto interna como externamente.

Pero para aspectos cualitativos, las encuestas son lo mejor, combinadas con conversaciones directas para obtener feedback honesto y mantener relaciones sólidas.

Ben Aston:

¿Y alguna estrategia para que los clientes llenen encuestas tipo net promoter score?

Brian Kessman:

La relación es clave: no solo envíes encuestas, ten conversaciones para que te vean como socio, no como alguien que solo pide datos. Si no responden, llámalos, siempre que haya una relación previa. Haz encuestas adaptadas a móviles para facilitar la respuesta. Pero, en general, todo depende de la relación con el cliente.

Ben Aston:

Perfecto. Muchas gracias por acompañarnos, Brian, ha sido genial conversar sobre construir y escalar equipos. Es un tema muy relevante, así que gracias por compartir.

Brian Kessman:

Gracias a ti, ha sido un placer, Ben.

Ben Aston:

Si quieres participar en la conversación, comenta en la publicación y visita la sección de comunidad en thedigitalprojectmanager.com para unirte a nuestro equipo de Slack donde hay muchas discusiones interesantes. Hasta la próxima, ¡gracias por escucharnos!