Proyectos PM/BSA

¿Por qué esta tarea?

Si eres nuevo en el mundo de Odoo, es probable que también seas nuevo en la industria de ERP. Comenzar proyectos al principio puede parecer una tarea compleja, ¡y tienes razón en pensarlo! Si bien nos hemos propuesto tener un software fácil de usar, Odoo varía en complejidad en términos de sus características. Con la complejidad añadida de las empresas de los clientes, a veces es demasiado para que una sola persona lo maneje, especialmente si recién has conocido Odoo.

A medida que nuevos analistas de servicios empresariales (BSA) ingresan a nuestra empresa todos los días, adoptamos un nuevo enfoque para incorporarlos a proyectos que están, al menos parcialmente, fuera de su zona de confort. En este enfoque, dejamos la mayor parte del trabajo funcional/de configuración a nuestro nuevo BSA y agregamos otra persona al proyecto, cuyo rol es actuar como gerente de proyecto (PM) para ese proyecto.

Esta tarea tiene como objetivo explicar cómo hacer que este enfoque sea suyo para su propio proceso de educación y de incorporación.

¿Cómo manejarlo?

Antes de la sesión:

• Lea la documentación a continuación; esta documentación explica todo el proceso con más detalle.

Durante la sesión:

• Haga sus preguntas con claridad y con frecuencia para facilitar su propia comprensión.

¿De qué trata esta tarea?

Comprender las ventajas de este enfoque PM/BA y cómo ponerlo en práctica.

¿Cuándo debemos considerar el enfoque de Gerente de Proyecto/Analista de Servicios de Negocio (PM/BSA) para implementar un proyecto?

Cuando un consultor alcanza un cierto nivel de experiencia, debe continuar su proceso de aprendizaje con consultores más experimentados para seguir progresando en sus conocimientos.

Además, con el enfoque PM/BSA, el BSA se sentirá más seguro y tendrá una oportunidad significativa de aprender más rápido, especialmente si se trata de uno de sus primeros proyectos. Asimismo, cuando un consultor ha adquirido experiencia a través de la implementación de sus propios proyectos, puede compartirla con otros consultores.

El enfoque PM/BSA debe tenerse en cuenta al iniciar un proyecto complejo o al transferir un proyecto complejo a un BSA. Esto permite que consultores con más experiencia participen en proyectos más grandes y, al mismo tiempo, les da tiempo para manejar otros proyectos simultáneamente.

Si tenemos en cuenta las variables de complejidad y el hecho de que cumplir con los plazos es primordial a la hora de llevar a cabo una implementación, resulta evidente que los proyectos complejos no pueden ser gestionados E implementados por la misma persona. Con dos personas en un proyecto, se entregará más rápido y se cumplirán las expectativas del cliente.

El enfoque PM/BSA es muy útil para que la BSA pueda participar en un proyecto más grande con alcances más amplios sin tener la responsabilidad directa total del proyecto. Ayudará a la BSA a abordar las necesidades del proyecto sin las limitaciones del estrés, la falta de experiencia, etc.

En general, considere la estrategia PM/BSA como una muy buena manera de acelerar el aprendizaje de los recién llegados o consultores con menos experiencia sobre las aplicaciones, la metodología, el manejo de situaciones difíciles, etc. Este enfoque brinda oportunidades para recibir retroalimentación del PM y para repensar las formas de trabajo (mediante comparaciones, desafíos, preguntas, etc.). Si todos trabajan en su proyecto en solitario, no mejorarán tanto ni tan rápido; trabajar juntos es una excelente manera de mejorar significativamente y rápidamente.

Tipos de proyectos que podrían beneficiarse de un enfoque PM/BSA:

• Ámbitos pequeños pero complejos: pocas aplicaciones pero flujos avanzados y complicados, muchos usuarios, uso complejo de Studio, etc.
• Amplio alcance y requisitos de desarrollos y/o integración.
• Proyecto a largo plazo: planificado a lo largo de varios meses/años con otros alcances previstos para el futuro (es decir, otras aplicaciones, otras integraciones, mejora de lo implementado, más usuarios, más empresas, etc.).
• Proyectos de alta prioridad con plazos cortos, que pueden requerir más consultores y que todos los involucrados trabajen rápidamente para respetar el plazo establecido por el cliente.

¿Cuáles son los perfiles necesarios para ambos roles?

• La BSA tiene suficiente experiencia relevante para realizar tantas tareas como sea posible por sí misma.
• Tanto la BSA como el PM han gestionado varios proyectos de forma autónoma.
• El consultor (PM) tiene suficiente experiencia para capacitar a otros y está dispuesto a asumir ese rol para mejorar los resultados del proyecto y continuar ampliando sus conocimientos.
• El consultor (PM) llega al proyecto con experiencia previa, ya sea trabajando con un BSA o capacitando a un especialista técnico. 
• El PM ya ha implementado una variedad de proyectos complejos, que abarcan casos que requieren una especialización profunda y/o casos que contienen amplios alcances.
• El PM y/o el BSA han trabajado en proyectos para diferentes tipos de clientes en una variedad de industrias y necesidades comerciales.
• La empresa está dispuesta y es capaz de capacitar a un colega y asumir otro rol en el proyecto además de simplemente implementar las aplicaciones.

Responsabilidades de la tarea

Esta metodología de gestión de proyectos es ideal para equipos compuestos por diferentes perfiles profesionales y niveles de experiencia, y es más adecuada para que todos los involucrados adquieran más experiencia.

El gerente de proyecto (PM) es, la mayoría de las veces, el consultor con más experiencia, mientras que el analista de servicios de negocios (BSA) es la persona con menos experiencia en comparación.

Responsabilidades del gerente de proyecto (PM): 

Durante la implementación del proyecto, el gerente de proyecto (PM) debe gestionar los siguientes aspectos:

• Crear un plan y gestionar su evolución durante el proyecto. 
• Garantizar la coherencia de la implementación a lo largo del tiempo y de los requisitos del cliente.
• Revisión de las especificaciones cuando se necesita un desarrollo.
• Asegúrese de que el BSA evolucione a lo largo del proyecto hacia un rol de PM.
• Proporcionar un cronograma claro de las tareas para hacer el trabajo de la BSA más simple y claro.
• Asegúrese de que la documentación del proyecto esté reunida en un solo lugar, sea clara y esté actualizada.
• Asegúrese de que el cliente y la BSA cumplan con sus plazos.
• Asegurarse de que el trabajo avance sin que se convierta en una tarea administrativa para todos.
• Consulte periódicamente con la BSA para ver cómo va el proyecto: cuáles son sus fortalezas, debilidades, etc.
• Apoyar a la BSA como entrenador; impulsar para que se lleguen a conclusiones mientras se crea espacio para que la BSA pueda aprender de forma natural. 
• Mantener la autoridad sobre el proyecto: reconocer y liderar a otros para superar desafíos, delegar tareas con frecuencia y claridad, ser claro y consistente con las expectativas, etc.
• Actuar como enlace entre todos los departamentos (por ejemplo, Ventas, Soporte, Desarrolladores) y los clientes. Deben tener una visión global de todo el proyecto y de todas las partes involucradas.

Tareas

Tanto el analista de negocios como el gerente de proyecto tienen tareas específicas que realizar, pero el gerente de proyecto también es el principal responsable de la gestión general del proyecto.

Analista de negocios

• Creación de usuarios y configuraciones estándar en la base de datos: CRM: configurar las etapas, leads, actividades, Inventario: almacenes, ubicaciones, rutas,..., Activación multiempresa,...
• Implementación de los flujos de la empresa Testing, Implementación, capacitación a usuarios finales, etc.
• Gestionar desarrollos: Si el proyecto requiere desarrollo, el BA puede redactar las especificaciones, asegurar el seguimiento, probar los desarrollos y dar retroalimentación al desarrollador,...
• Importaciones manuales: Contactos, Productos, Oportunidades, Facturas, Asientos contables, elaboración de plantillas de importación.
• Personalizaciones del estudio: Añadir campos, modelos, menús, cambiar las etiquetas,...

Gerente de proyecto

• Correos electrónicos de seguimiento y estado del proyecto al cliente.
• Gestión de la planificación y de las tareas pendientes de cada uno: plazos de ejecución de cada tarea, priorización de tareas. 
• Asignar tareas específicas y concretas al Analista de Negocio.
• Ayuda en la configuración más avanzada para ciertos flujos que el BA no puede realizar solo.
• Revisa y valida las tareas realizadas por el BA (especificaciones, importaciones, configuraciones, personalizaciones,...).
• Valida los desarrollos.
• Gestiona y mantiene reuniones recurrentes con el cliente.
• Gestiona y mantiene reuniones con el BA para realizar el seguimiento del estado del proyecto.
• Responsable de decisiones globales: 
• ¿Qué se puede y/o se entregará en el plazo establecido por el cliente y qué no? Ejemplo: El cliente quiere integrar Odoo con su software, añadir una funcionalidad en la aplicación CRM,... => El PM evaluará la viabilidad de la solicitud dentro del tiempo asignado y tomará la decisión de hacerlo, no hacerlo o hacerlo más tarde.
• Si hay el más mínimo problema en la implementación: no hay más horas disponibles en el pack, quejas de los clientes por cualquier motivo, ..., es el PM quien tiene que tomar las decisiones y participar en estas discusiones.

Puede utilizar la siguiente tabla para explicar visualmente al cliente la distribución de tareas en un proyecto de PM/BA. De esta manera, los consultores y el cliente tienen una idea global de la división de tareas.

Misión del Primer Ministro

Su misión global es sacar al analista de negocios de su zona de confort sin apresurarlo: 

• Desde el principio, involucrelos en las reflexiones y análisis.
• Pregúnteles qué entendieron sobre el flujo y qué soluciones pueden sugerir. 
• Pensemos juntos cómo se podrían llevar a cabo los desarrollos.
• Explica cómo priorizas las tareas y por qué las priorizas de esta manera.
• Comunicar los próximos pasos en la implementación del proyecto y cuáles serán los roles y responsabilidades de cada uno.
• Progresivamente, darles la responsabilidad de algunas partes del ámbito de aplicación, complejas pero sin riesgos.
• El BA realizará la mayoría de las llamadas solo.
• El BA implementará de A a Z una aplicación o un flujo completo, podrá regresar al PM si es necesario o si hay un gran punto de bloqueo.
• Darles la responsabilidad de algunos aspectos de la gestión del proyecto.
• Organizar y gestionar llamadas o reuniones.
• Gestionar las comunicaciones con el cliente: estado del proyecto, avances del desarrollo, solicitudes de pruebas y validaciones,...
• Reuniones con el desarrollador y asignación de tareas y pendientes.
• Establezca los próximos plazos. 
• Asegúrese de que el proyecto se entregará dentro de las horas restantes. De lo contrario, dígale al departamento de ventas, al cliente y al gerente de proyecto que, en su opinión, esto no será posible.

El PM no sólo tiene que ejecutar el proyecto, sino que también tiene un papel de formación. El BA debe beneficiarse doblemente de la experiencia del PM como Project Manager y como coach.

En algún momento, el objetivo es que el PM se retire del proyecto y deje toda la responsabilidad del mismo al BA. Esta transición debe ser natural cuando el PM sienta que el BA tiene el control del proyecto al 100%: flujos, comunicaciones, plazos, responsabilidades de todos los involucrados en el proyecto, etc.

Transferir la responsabilidad total al BA en algún momento demuestra que el enfoque PM/BA ha funcionado bien y da satisfacción al BA, que se convierte en el único consultor del proyecto.

¿Quién tiene que llevar una hoja de horas?

Dos consultores:

• Reuniones internas de seguimiento del proyecto.
• Reuniones de inicio, reuniones de alineación, reuniones de preproducción: el beneficio de tener dos personas en dichas reuniones es más importante que tener que perder tiempo después volviendo a explicar cosas que se habrían dicho. 
• Tiempo dedicado a especificaciones y pruebas de desarrollos.
• Tiempo dedicado al análisis de flujo o a preguntas abiertas para proponer la mejor solución al cliente. Se suele decir que hay más ideas en dos cabezas que en una.

Un consultor:

• Tareas Individuales Asignadas: Importación, configuración de los flujos, investigación, pruebas,.. 
• Cada momento que el consultor trabaje en el proyecto, deberá ser el único consultor de la hoja de tiempo: importación, configuraciones, redacción de correos, pruebas, investigación,...

Todo consultor debe conocer qué puede o no ser parte de horas para el cliente. La correcta distribución de las partes de horas evitará problemas con el cliente. Es responsabilidad del gerente de proyecto asegurarse de que el analista de negocios haga sus partes de horas correctamente: capacitación interna vs. proyecto.  

Poner el proyecto en “Soporte”

En general, una vez que una fase del proyecto entra en producción, el director de proyecto debe asegurarse de que las demás etapas aún estén bien definidas y que el resto del proyecto aún sea factible dentro del marco de tiempo planificado.

A partir de este momento, el BA debe asumir cada vez más responsabilidad y debe sustituir gradualmente al PM.

Una vez que el proyecto está en marcha, el BA es el único referente del proyecto. El PM ya no debe intervenir, salvo en casos de extrema urgencia.

Comunicación y reuniones

Antes de comenzar el proyecto, el PM y el BA deben discutir cómo quieren comunicarse entre sí para gestionar el proyecto: documentación del proyecto y medios de comunicación (hangout, discord, correo,...),...

Por supuesto, no existe una regla perfecta porque depende de cada proyecto, del número de personas involucradas, de la duración del proyecto,...

Sin embargo, se recomienda tener al menos una vez a la semana una llamada de implementación con el BA y una llamada de Gestión del Proyecto una vez cada dos semanas. Al mantener un contacto regular con el cliente, el proyecto avanzará más rápido y ninguna de las partes involucradas puede perder el hilo del proyecto.

La comunicación o número de reuniones entre el PM y el BA también depende del tipo de proyecto y de la necesidad de intercambio de información entre el PM y el BA.

Debería haber al menos una reunión por semana entre el PM y el BA:

• Proporcionar una actualización sobre el proyecto.
• Hablando de puntos de bloqueo: bloqueo en un flujo, cumplimiento de plazos,...
• Discuta temores o dudas sobre la implementación.

A continuación se presentan algunas buenas prácticas para mejorar la comunicación entre todas las partes interesadas:

• Poner el PM/BA en cc al intercambiar correos electrónicos con el cliente.
• Realice una reunión entre el PM y el BA antes de una llamada para prepararse para ella.
• Realice una reunión PM/BA después de una llamada para informar y establecer nuevas tareas por hacer.
• El BA debe invitar al PM a todas las llamadas incluso si el PM no participa en ellas.

Diferentes enfoques para PM/BSA

En el contexto de un enfoque PM/BSA, en la mayoría de los casos, el gerente de proyecto también tiene el rol de analista de negocios. El analista de negocios no tiene un rol de gerente de proyecto al comienzo del proyecto, pero el objetivo de este enfoque es hacerlo evolucionar hacia esta responsabilidad.

Puede haber varios enfoques para completar un proyecto PM/BA.

Enfoque estándar:

El enfoque que hemos descrito anteriormente es en el que el PM gestionará todo lo que es la gestión del proyecto y tomará las decisiones importantes, mientras que el BA garantizará la buena implementación del proyecto siguiendo la metodología de inicio rápido.

En términos de planillas de horas, se estima que el PM se ocupará del 25% de las horas trabajadas y el BA del 75%. 

Enfoque complementario:

BA y BA: ambos hacen tanto BA como el otro y se dividen las tareas. Uno de los dos BA pasa más tiempo haciendo el rol de PM, pero ambos están ocupados con el cliente e implementando el proyecto. Cada uno tendrá sus tareas y el cliente se comunicará con ambos en relación con los aspectos de implementación funcional del proyecto.

Tenemos este tipo de enfoque cuando el proyecto requiere de dos consultores experimentados o con la misma experiencia porque la configuración es bastante compleja y avanzada.

En términos de hojas de horas, se estima que el PM/BA registrará las horas en un 50% y el BA en un 50%.

Beneficios para el cliente

Las dos partes interesadas que deberían beneficiarse de este enfoque son el cliente y Odoo:

- El cliente debe ver directamente un valor añadido a su proyecto al contar con varios consultores en lugar de uno solo.

- Odoo porque con este enfoque, la experiencia de ambos consultores evolucionará más rápido y será útil para el resto del equipo.

Lo más importante es que el cliente nunca debe cuestionar el enfoque. Debe ver en todo momento los beneficios de este enfoque:

• El ritmo del proyecto será mayor. El cliente podrá contar con varios consultores en lugar de uno solo y, por lo tanto, la implementación será más rápida. Los consultores pueden trabajar simultáneamente en el proyecto y dividir las tareas de diferentes maneras. 
• Si un consultor no está disponible, el otro siempre estará disponible para respaldarlo. Por lo tanto, la disponibilidad de los consultores es mejor para el cliente. 
• El cliente se siente tranquilo al saber que hay una persona con experiencia en su proyecto y sabe que su proyecto se implementará correctamente. Esto aumenta la confianza del cliente y, si surge un problema, sabe que se solucionará correctamente. 
• Tener dos cerebros es mejor que tener uno. 
• La importancia o el tamaño del proyecto requiere que haya varios consultores en el proyecto. El cliente ve que Odoo está considerando su proyecto. 

Lo más importante es que el cliente haya comprendido el objetivo del enfoque desde el principio. Este enfoque debe ser explicado primero por el vendedor y luego por el gerente de proyecto durante la llamada de KO para que el cliente sepa qué esperar y comprenda directamente los roles de cada persona.

Consejos y trucos

• Organizar reuniones al menos una vez por semana entre el PM y el BA. 
• Organizar reuniones antes o después de la llamada entre PM y BA. 
• Disponer de una única herramienta para compartir conocimientos y documentar proyectos.
• Al final de cada llamada, el BA envía un correo electrónico de resumen al cliente con el PM en copia, no solo como información sino también como respaldo en caso de que el PM tenga que volver a algunos puntos específicos que se discutieron o en caso de que la otra persona tenga una ausencia inesperada.
• El BA debe invitar al PM a todas las llamadas incluso si el PM no participa en ellas. 
• Durante la KO, el PM le explicará al cliente cómo se llevará a cabo el proyecto en presencia del cliente y la metodología. El BA se encargará de la parte comercial, al hacer esto, el BA se involucra directamente en el proyecto. Tenemos que seguir este enfoque solo si no es el primer proyecto del BA. Si es el primer proyecto del BA, entonces el PM se encarga de toda la KO.
• No involucre al BA en discusiones comerciales, o errores técnicos,... 
• Si el BA tiene alguna pregunta, debe hablar directamente con el PM para no perder tiempo en la implementación del proyecto y ser lo más eficiente posible. Si el BA tiene preguntas para hacerle al PM, debe hacer una lista con todas las preguntas en lugar de venir a hacerlas en diferentes momentos.
• Durante la llamada inicial, el gerente de proyecto debe encargarse de toda la metodología y el analista de negocios debe encargarse de la parte comercial. De esta manera, el analista de negocios participa directamente en el proyecto durante la primera llamada. El gerente de proyecto puede intervenir durante la parte comercial si hay cosas que deben agregarse. 
• El PM tiene más experiencia y por lo tanto entrará en menos detalles que el BA, por eso es muy recomendable dejarle el liderazgo al BA en el lado comercial.
  
  

Para evitar

• El primer ministro da órdenes y el ministro de Finanzas las ejecuta.
• Nunca celebren reuniones internas y sólo se copien unos a otros en los correos electrónicos. 
• No darle suficiente responsabilidad al BA.
• Revisar todo lo que ha hecho la BA / no darles suficiente libertad.
• No mantener informado al otro consultor del estado del proyecto.
• Bloqueo del proyecto por falta de disponibilidad de los consultores porque ambos consultores no pueden estar presentes al mismo tiempo. Favorecer una llamada con el cliente aunque no estén todos presentes, en lugar de posponerla cuando no sea necesariamente relevante.
• El PM asume demasiada responsabilidad en el proyecto y aplasta al BA. En este caso, el cliente notará directamente la diferencia de experiencia entre los dos consultores y no verá el valor agregado de tener 2 consultores en el proyecto. 
• El BA depende demasiado del primer ministro.
• El analista de negocios está demasiado estresado y no sabe qué hacer. El objetivo de este enfoque es que el analista de negocios aprenda de sus errores y reciba orientación del gerente de proyectos. 
• El BA no tiene una visión global del proyecto (importancia de las reuniones PM/BA).
• Estos desarrollos son gestionados únicamente por el Primer Ministro sin involucrar al BA.

Producción

Después de revisar esta lista, podrá administrar algunos proyectos con una configuración de PM/BA. Tenga en cuenta que, como socio, puede pedirle a Odoo que desempeñe ese papel de PM si es necesario.