Salva Tu Proyecto Con Un Documento de Inicio de Proyecto (con Maik Stettner de FCV Interactive)

Lee la transcripción:

Estamos probando la transcripción de nuestros podcasts usando un programa de software. Disculpa cualquier error tipográfico, ya que el bot no es 100% preciso.

Ben Aston:

Gracias por sintonizarnos. Soy Ben Aston y esto es el pódcast de Digital Project Manager. Este pódcast está presentado por Clarizen, el líder en software de gestión de cartera, proyectos y empresas. Visita clarizen.com para saber más.

Si hay algo que puedas garantizar sobre un proyecto, es que nunca saldrá como estaba planeado, pero ¿por qué fracasan los proyectos? A veces, simplemente es porque comenzamos los proyectos demasiado rápido y vemos la fecha límite cada vez más cerca, y terminamos iniciando el proyecto en un estado de pánico ciego; pero luego, cuando las cosas empiezan a salir mal, nos preguntamos por qué.

Aunque normalmente tenemos todo el contexto, la estrategia, los detalles, los requisitos, las métricas de éxito, guardados en la cabeza, a menudo cometemos el error de pensar que, por tanto, los demás también deberían saberlo todo, pero la realidad es que, si no está documentado, lo más probable es que nuestro equipo simplemente no lo sepa.

Así que hoy vamos a hablar de una herramienta que podemos usar para lograr que todos estén alineados desde el inicio del proyecto. Es el Documento de Inicio de Proyecto, o más comúnmente llamado en nuestro sector, el Brief de Proyecto. Así que hoy te vamos a dar la clave interna sobre cómo puedes crear un PID y usarlos para hacer que tus proyectos sean más efectivos.

Hoy estoy acompañado por Maik Stettner. Uno de mis amigos y colegas. Maik es uno de nuestros expertos residentes de DPM en The Digital Project Manager. Bienvenido, Maik.

Maik Stettner:

Hola. ¿Cómo estás?

Ben Aston:

Bien, genial tenerte con nosotros, así que Maik, hablemos primero de ti y cuéntale a todos un poco sobre tu historia porque, obviamente, trabajamos juntos y llevamos colaborando ya… ¿son cinco años?

Maik Stettner:

Sí, son entre cuatro y cinco años ya.

Ben Aston:

Sí. Cuando contraté a Maik, recuerdo que pensé: “Oh, no sé si este chico podrá hacerlo”. Porque vienes de un trasfondo un poco diferente. No el típico de agencias tradicionales. Cuéntanos tu historia. ¿Cómo fue que te convertiste en PM en una agencia digital?

Maik Stettner:

Sí, en total tengo unos 10 años de experiencia en diversos campos. Originalmente empecé en videojuegos y publicaciones, gestionando lanzamientos de juegos en Europa y Norteamérica, y después pasé a otros campos como bases de datos médicas, pero en general siempre en desarrollo de software y cosas que tienen que ver con gestión de proyectos, una variedad de equipos, etc. Y también dentro de mi carrera acumulé experiencia en agencias, con desarrollo de apps y algo de desarrollo web inicial también. Básicamente, cuando tuvimos esa primera conversación sobre trabajar juntos, hice el cambio total a desarrollo web y agencia.

Ben Aston:

Sí.

Maik Stettner:

Y sí, llevo trabajando con mi empresa actual, FCV, unos cuatro años y ahora lidero el equipo de Gestión de Proyectos en la agencia y soy básicamente responsable de la entrega global de los proyectos y asegurarme de que los clientes están satisfechos con los resultados que brindamos.

Ben Aston:

Genial. Entonces, para aquellos que están escuchando y piensan... Bueno, tal vez estén en una situación similar, y creo que esto nos pasa seguido, es gente que dice, “Vale, soy Project Manager, tengo experiencia gestionando software, pero ahora estoy pensando en pasar a una agencia y ser Digital Project Manager.” Para ti, ¿cómo fue la transición de un entorno más de software a uno de gestión digital de proyectos en agencia? ¿Cuáles fueron las diferencias clave en la forma de gestionar personas o proyectos? Me gustaría entender más sobre el contraste y sobre lo que deberían pensar quienes están considerando ese cambio para prepararse bien.

Maik Stettner:

Sí, primero que nada, hay muchos paralelismos. Lo que te encuentras en otras agencias de desarrollo de software, o en otros campos relacionados con la gestión de proyectos, también lo verás en una agencia. Equipos diversos, proyectos que se descarrilan por diversas razones, y puedes aplicar las mismas tácticas para reconducir esos temas.

Una de las diferencias principales para mí fue entender y aplicar la idea de enfocarse mucho en tiempo y materiales y entregar pequeños incrementos de trabajo en lugar de grandes proyectos; porque los clientes, especialmente en el campo en el que trabajo, quieren tener más transparencia y más control sobre cargas de trabajo más pequeñas. Eso requiere reportes más detallados y, en general, supone más esfuerzo en ser transparente y explicar al cliente exactamente lo que estás haciendo para generar ese nivel de confianza. Lo cual siempre requiere un poco más de esfuerzo y fue un ajuste necesario respecto a cuando trabajas en una empresa de producto, donde apuntas solo a un lanzamiento, que puede ser interno.

Esa fue la principal diferencia, pero resultó interesante ver que, aunque trabajes en un campo completamente distinto, no importa si es una base de datos, un juego o un sitio web, te enfrentas a retos muy similares que se pueden trasladar de un sector a otro; y si aplicas lo aprendido en tu trabajo anterior, como la buena comunicación y mejores prácticas estándar como Project Manager, lo más probable es que tengas éxito, no importa lo que estés construyendo.

Ben Aston:

Sí, eso es genial. Entonces, cuéntanos… Hablaste de algunos de esos retos similares. ¿Nos puedes contar, en tu papel actual, no solo gestionas proyectos sino equipos también, así que en cuanto al equipo de Gestión de Proyectos, y gestión de cartera de proyectos, gestionando un conjunto de proyectos con requisitos y recursos en conflicto… ¿Cuáles son los retos habituales que gestionas liderando el equipo PMO?

Maik Stettner:

Mi rol ahora es más holístico, así que formato que todo siga moviéndose y una de mis principales funciones es... como ya dijiste, la mayoría de las veces es recursos: asegurarme de tener la gente adecuada para el trabajo adecuado y durante el tiempo adecuado.

Ben Aston:

Sí.

Maik Stettner:

Porque, a menudo, tienes que comprometerte si algo tarda más y ya tienes un nuevo proyecto programado; y entonces, debes mitigar esos ajustes necesarios y asegurar que los clientes tengan una línea abierta conmigo porque el riesgo de un rol más holístico y de alto nivel es básicamente que eres el responsable de las escaladas, y nadie quiere ser solo esa persona, porque eso significa que solo te llaman si están molestos.

Ben Aston:

Sí.

Maik Stettner:

Pero siempre es bueno participar activamente en varios proyectos para fortalecer la relación de confianza, y aun así asegurar la correcta estructura interna. Sea para asignación de recursos, operaciones, o simplemente en colaboración general porque tenemos varias sedes.

Para nosotros, es importante asegurarnos de que la gente de nuestra oficina de Toronto trabaje bien con la de Victoria, por ejemplo. Así que ese es el centro de mi trabajo. Aun así, sigo gestionando algunos clientes con los que trabajo de cerca y sigo haciendo bastante gestión de proyectos porque me sigue apasionando y me encanta trabajar con personas, así que no pienso dejarlo de lado.

Ben Aston:

Sí. Entonces, volviendo al desafío de la gestión de recursos, que todo líder de equipo o gestor de recursos enfrenta, ¿cuál es tu enfoque cuando tienes proyectos en conflicto, dos Project Managers y ambos necesitan el mismo recurso para el viernes? ¿Cómo lo priorizas o cuál es tu enfoque para decidir quién gana? Esto es algo que muchos PMs mencionan todo el tiempo. No tienen recursos para sus equipos, así que ¿cómo lo decides? Danos tu visión sobre este asunto: ¿cómo decides qué proyecto sigue adelante y cuál se pospone? ¿Qué puedes compartir sobre tu proceso para equilibrar recursos?

Maik Stettner:

Sí. Primero, normalmente evalúo la prioridad del proyecto. ¿Existe algún tipo de deadline comprometido con el cliente? ¿Debe salir en una fecha concreta? Reviso si hay flexibilidad en los tiempos.

El hecho de que algo esté cerrado en contrato cuenta también; así que, asegurando que todo esté avanzado. ¿Solo quieren adelantar y hacer un favor al cliente? Está bien y lo hacemos si hay tiempo, pero si otro proyecto va en vivo en tres días, probablemente no podemos sacar a nadie de ese equipo.

Eso es la base. Idealmente, no debería pasar, porque el Project Manager debe prever los sobrecostes y prever colchones y, aunque suene extraño, espero de mi equipo que también peleen por los recursos.

Ben Aston:

Sí.

Maik Stettner:

A veces son demasiado amables y dicen, “Vale, puedes tener a esta persona un día.” Y eso termina en que todo se retrasa. No me gusta robar recursos, eso es inaceptable; pero en las reuniones de recursos, espero que alguien defienda el tiempo que necesita y que lleve el problema al gerente de recursos para que ayude o equilibre la situación.

Ben Aston:

Tal vez sea un problema de gestión de recursos canadiense.

Maik Stettner:

Sin duda, un pulso canadiense.

Ben Aston:

Los canadienses son muy amables, lo decimos como europeos, ¿no? ¿O solo entre canadienses pueden bromear de esto?

Maik Stettner:

Exacto. Yo también lo veo distinto en Europa.

Ben Aston:

Cuéntanos, me interesa mucho el tema de herramientas. ¿Has encontrado alguna herramienta últimamente que te haya sorprendido y dijiste “¿por qué no usamos esto antes?” ¿Cuál es tu kit de herramientas favorito?

Maik Stettner:

¿Te refieres a gestión de recursos o…?

Ben Aston:

Bueno, en gestión de recursos o en herramientas de gestión de proyectos en general.

Maik Stettner:

En realidad utilizamos un kit de herramientas bastante estándar para la gestión del tiempo, y MS Project suele ser abrumador para el cliente. Estamos experimentando con productos en la nube. Por ejemplo, Project tiene una versión en Office 365. Pero también buscamos soluciones para gestión del tiempo y gestión de recursos. No he encontrado la solución perfecta porque tenemos un proceso muy personalizado que, lamentablemente, es parcialmente manual también.

Personalmente, creo que la herramienta ideal para lo que necesitamos no existe realmente. Mi objetivo sería construir algo o personalizar una herramienta adaptada a nuestras necesidades.

Ben Aston:

Dinos, ya que hay quien crea herramientas que nos escucha: ¿Qué te falta en las herramientas para que sean realmente útiles? ¿O es el proceso tan complejo que no existe la herramienta adecuada aún?

Maik Stettner:

No necesariamente, en realidad es bastante sencillo. Pero lo que busco es una herramienta que cubra desde la gestión del tiempo y partes de reservas y horas, o time-sheets del personal, hasta la planificación de recursos. Algo como Resource Guru u otras herramientas que permitan planificar lo que necesitas, pero también desde el aspecto financiero. Sobre todo en tiempo y materiales, lo simple es multiplicar horas por tarifa. Y después, establecer informativos y reportes desde allí.

Parece fácil, pero hay muchas cuestiones a considerar, como la probabilidad de cierre de proyectos, los cambios, y cómo los sistemas gestionan eso. Eso puede trastocar los reportes y añadir mucho trabajo manual que desajusta las métricas. No he encontrado aún la solución perfecta.

Ben Aston:

Genial. Hablemos sobre el artículo que escribiste sobre los documentos de inicio de proyecto o los PIDs. Como mencioné al inicio, los proyectos suelen salir mal porque no los empezamos bien. Suponemos lo que el equipo sabe o les damos muchos documentos y decimos, “Están todos en el drive compartido, leedlos.” Pensamos que van a revisarlos y ponerse al día, pero si fallan, no entendemos por qué, pero la realidad es que no entienden el proyecto.

Hablemos de cómo podemos hacerlo mejor, cómo escribir mejores briefs de proyecto, o mejor dicho, usando el término de gestión de proyectos, crear ese documento de inicio de proyecto. Para ambientar un poco: si puedes darnos el trasfondo o tu proceso de lanzamiento de proyectos y dónde encaja este documento de inicio de proyecto o briefing. ¿Cuándo lo creas? ¿Qué haces hasta llegar al punto de poder redactar ese documento?

Maik Stettner:

Normalmente, supongamos que tienes un nuevo cliente. Te emociona porque el macro-contrato está firmado, tal vez un acuerdo marco de servicios que estipula la colaboración entre ambas empresas. El siguiente paso para mí es averiguar cómo llevar eso a pasos concretos y términos claros.

Normalmente, lo que me viene a la mente es el alcance del trabajo (SoW). El problema es que, tan temprano en el proyecto, todo es muy superficial, apenas una aproximación de lo que acabarás haciendo. El documento de inicio y la reunión de lanzamiento son útiles para escuchar al cliente y detectar factores que no consideraste en el alcance inicial.

Normalmente, una vez que el alcance inicial está redactado (puede estar en borrador aún), el equipo lo evalúa dentro de la agencia en una mini reunión interna para alinear a todos; luego hay una reunión externa con el cliente para explicar quién es el equipo, la colaboración, y el alcance definido.

El documento de inicio o brief es para mí el siguiente paso de concreción. Aunque a esa altura sigue siendo un documento vivo porque no tienes todos los detalles, es una excelente herramienta para dar contexto de negocio y asegurar que los parámetros básicos del proyecto son claros, no solo para el cliente sino para el equipo interno.

Ben Aston:

Sí, entonces, tras el contrato y el SoW, llega ese documento que define detalles, sea junto al SoW o refinándolo. En tu artículo enumera cosas para incluir: contexto, parámetros, estructura de desglose de trabajo, equipo y gestión de riesgos. Hablemos del contexto primero. Al reunir el documento, ¿cómo proporcionas contexto sin abrumar? ¿Cómo distingues la información útil del ruido? ¿Qué incluirías sí o sí en esa descripción contextual?

Maik Stettner:

Sí. Creo que se trata de por qué el cliente hace el proyecto y qué problemas resuelve a alto nivel. ¿Existen motores de negocio? ¿Quieren aumentar ventas, educar una audiencia o hay un rebranding? ¿Cómo se define el éxito? Aunque estemos a un alto nivel, debemos saber cómo sabremos, al final, si triunfamos.

Puedes decir que es tan sencillo como mejorar ventas, o, por ejemplo, que haya mejores conversaciones comerciales, o para tu web de autoservicio, que se gestione el contenido. Es importante contextualizar para que el equipo sepa lo que busca. Aunque aún falten pasos detallados, ayuda a enmarcar la actividad.

Si el proyecto era de rebranding y alguien pregunta luego, “¿Por qué no aumentaron las ventas?”, puedes volver y decir, “Ese no era el objetivo indicado en el contexto del proyecto.” Pero podría influir positivamente aunque no era el foco.

Siempre es bueno mantener esto como registro de lo discutido y para alinear los objetivos globales con el cliente.

Ben Aston:

Sí, creo que ese contexto siempre es útil, salvo en proyectos de mantenimiento puro, donde no ves estrategia global. Pero si se crea algo nuevo, comprender los motivos, metas y criterios de éxito es clave para dar contexto útil al equipo y perfilar la solución. Contextualizar en el brief o documento de inicio es fundamental. Hablemos de los parámetros, porque el contexto sitúa el proyecto en la estrategia global. ¿Qué parámetros delimitas? Básicamente, pones restricciones. ¿En qué sentido ves positiva esa delimitación?

Maik Stettner:

No quieres restringir a los expertos, pero si les das rienda suelta, podrían estar haciendo algo muy distinto a lo que imaginabas. Es importante darles el marco con restricciones, como presupuesto, cronograma y calendario. Idealmente, ya has estimado con ellos, así que no debe ser nada nuevo; y es bueno que sepan el presupuesto y que no habrá sorpresas por mostrarlo al equipo.

Es valioso repasar esos temas. Es importante que para el equipo no sea una restricción sino lo acordado con el cliente para entregar a cierto coste. Incluso si algo cambia y alguien del equipo piensa, “Necesito más tiempo,” deben debatir, “Bien, así podemos lograrlo igualmente.” Es bueno que el equipo entienda que estamos para ayudarlos con aumentos de presupuesto o riesgos tempranos y cambios de plazos.

Al final, el equipo debe confiar en la entrega y entusiasmarse tanto como el cliente; también quieren que las cosas se hagan.

Ben Aston:

Hablaste también de otras cosas importantes. Sin desvelar el artículo, quería hablar de la estructura de desglose de trabajo y el plan de recursos. Cuando todavía todo está poco definido, ¿cómo armas un plan inicial? ¿Cómo crear un plan cuando aún no sabes con exactitud qué será el proyecto? ¿Qué opinas?

Maik Stettner:

Sinceramente, es la mejor estimación posible en ese momento. Seguramente te basas en el SoW o el presupuesto creado por el equipo. Hay muchas variables por despejar: ¿El cliente responde? ¿Cuántas revisiones? Son posibilidades. El plan inicial puede no cumplirse.

Pero mirando atrás, a lo complicado de una agencia y por eso lo digo: aunque sea solo una aproximación, ayuda a que tanto la agencia como los demás equipos puedan planificar recursos y mantener estabilidad. Aunque el plan inicial sea ambicioso y el cliente pida más tiempo luego, ayuda a mapear todo desde tu perspectiva y a entender los matices para explicar al cliente y hacer las preguntas correctas. Tener un plan, aunque sea aproximado, es mejor que nada porque genera debate y con el tiempo se irá puliendo.

Ben Aston:

Al menos ya tienes algo y puedes mejorarlo; mejor eso a no tener nada. Si inicias un proyecto y reúnes al equipo para el brief sin un plan real y nadie pensó en dependencias o rol del cliente, arrancas sin impulso. Pero si tienes un plan, aunque esté mal, al menos tienes algo sobre lo que debatir y decir, “Maik, estás loco, ¿cómo haremos eso?” Mejor eso que una hoja en blanco.

Hablamos del brief, el documento de inicio, que suena a documento muy formal, pero en realidad puede adoptar muchas formas. ¿Qué otros formatos ves tú para el brief y cómo crees que evoluciona su rol a lo largo del ciclo de vida del proyecto?

Maik Stettner:

La guía que yo armé es solo un ejemplo. Hay un mínimo de información que debe tener un documento de inicio o brief, pero hay otras maneras de hacerlo. Por ejemplo, puedes abordar la gestión de riesgos y documentarla a parte, o un cuadro RACI incluido en los informes de estado, etc.

No hace falta que sea súper formal. Lo importante es que todos lo aprueben, ya sea en SharePoint, BaseCamp, o que se itere y se converse sobre ello. Si, por ejemplo, el proyecto avanza y se acuerda, “Al estimar nos olvidamos del área de ventas, hay que incluirlo,” y eso tiene impacto en el alcance.

Mientras sea un documento, incluso un email formal, algo escrito en lo que todos estén de acuerdo y lo reconozcan. No hace falta firma oficial, pero sí que sea reconocido y aceptado, porque será la base del trabajo.

Ben Aston:

Genial. La buena noticia es que si sigues pensando tras oír esto que todo suena bien, pero ¿por dónde empiezo? Maik ha creado una muy buena plantilla que puedes usar para tu brief o documento de inicio de proyecto. Consulta el artículo para descargarla. Pero Maik, muchas gracias por estar hoy con nosotros. Ha sido un placer tenerte aquí.

Maik Stettner:

Sí, gracias por invitarme.

Ben Aston:

De nada. Como uno de nuestros expertos DPM, si te ha gustado lo que cuenta Maik, él participará en nuestro próximo curso que empieza en septiembre llamado Dominando la Dirección de Proyectos Digitales. Si no sabes a qué me refiero pero sabes que necesitas formación en PM, míralo. Es un curso de siete semanas con lecciones en vídeo, tareas semanales, debates de grupo y opción de coaching. Visita digitalprojectmanagerschool.com y apúntate antes de que se llene.

Si te gustaría contribuir a la conversación sobre documentos de inicio de proyecto o briefs, entra en la sección de recursos de digitalprojectmanager.com para unirte a nuestro equipo de Slack, donde siempre hay conversaciones interesantes, y recuerda también comentar en el artículo y compartirlo. Hasta la próxima, ¡gracias por escucharnos!