Trabajo en una pequeña agencia digital donde tenemos los siguientes roles:
Nuestro trabajo diario es una mezcla de proyectos planificados, soporte y mantenimiento para clientes existentes, y lanzamiento y alcance para nuevos negocios.
Antes de que comenzara nuestro PM, teníamos muy pocos procesos implementados y poca o ninguna planificación de recursos. La naturaleza del negocio dificulta la planificación de recursos, ya que tenemos mucho trabajo de apoyo y, con frecuencia, tenemos trabajos que llegan con muy poca antelación y plazos breves que requieren que los recursos se retiren del trabajo del proyecto planificado.
Como estábamos haciendo un trabajo terrible en la gestión de recursos, decidimos contratar a un Gerente de Proyecto. Cuando comenzó, afirmó su forma preferida de trabajar, que consistía en enviar un correo electrónico todas las mañanas con una lista de tareas para hacer ese día para todos, excepto el MD. Luego pediría que todos le enviaran un correo electrónico una hora antes del final del día indicando el progreso de cada uno de sus tareas.
Este enfoque pronto comenzó a agradar a la gente, especialmente al socio y al líder tecnológico. Parecía una microgestión al extremo y no dejaba espacio para las tareas generales no programadas que surgen día a día.
Durante bastante tiempo, la mayoría de la gente se olvidaba de enviar su correo electrónico de actualización al PM cerca del final del día y, finalmente, aceptó que podría no ser la forma más eficiente de trabajar.
El área principal de confusión es dónde deben terminar las funciones del PM y comenzar las del Tech Lead. El PM tiene muy poco conocimiento técnico pero asume el rol de asignar tareas individuales a los Desarrolladores, Diseñador y Líder Técnico. Esto conduce con frecuencia a que las tareas se asignen a las personas equivocadas y también frustra al líder técnico, ya que siente que esto debería ser parte de su función.
¿Un PM normalmente estaría asignando tareas detalladas a personas en un equipo pequeño, o tenemos un PM demasiado entusiasta?
¿Un PM normalmente estaría asignando tareas detalladas a personas en un equipo pequeño [?]
Tu pregunta no es determinista. La gestión de proyectos es simplemente una disciplina; el alcance de la función de gestión de proyectos está definido por cada organización. Su organización debe reevaluar sus objetivos de gestión y reestructurar su proceso de desarrollo en consecuencia.
El estilo de comando y control de la gestión de proyectos se practica ampliamente, especialmente en organizaciones que adoptan marcos de gestión de proyectos no ágiles. Si el rol se ha definido como un rol autoritario, a menudo se espera que un PM asigne tareas y "responsabilice a las personas".
Cada vez que se responsabiliza a un PM por hacer cosas que perjudican a la organización, la organización debe reevaluar cuidadosamente lo que espera del rol y cómo espera medir el éxito de ese rol. Evaluar un PM basado en el desempeño de los miembros del equipo es como pedir un comportamiento de comando y control; si eso no se desea, la alta dirección debe reestructurar el equipo y/o la función de gestión del proyecto.
Como estábamos haciendo un trabajo terrible en la gestión de recursos, decidimos contratar a un Gerente de Proyecto. Cuando comenzó, afirmó su forma preferida de trabajar, que consistía en enviar un correo electrónico todas las mañanas con una lista de tareas para hacer ese día para todos, excepto el MD. Luego pediría que todos le enviaran un correo electrónico una hora antes del final del día indicando el progreso de cada uno de sus tareas.
En otras palabras, la organización tenía un problema, hizo su diligencia debida al contratar a alguien que defendía una filosofía que encajaba con el estilo de gestión deseado por la gerencia y ahora no le gusta por aplicar los controles para los que fue contratado. Esta no es una receta para el éxito.
Hay dos opciones aquí:
Dudo sinceramente que el primer ministro decidiera que "podría no ser la forma más eficiente de trabajar". Parece más probable que simplemente se cansó de recibir críticas por tratar de imponer cierta estructura en su equipo.
Nada de esto quiere decir que no haya una brecha de habilidades blandas aquí, o que no haya otras metodologías de gestión de equipos que puedan ser más efectivas en su organización en particular. Sin embargo, según los antecedentes que proporcionó, ciertamente parece una falla de liderazgo en los rangos gerenciales, en lugar de una falla por parte del primer ministro.
No... dejó espacio para las tareas generales no programadas que surgen día a día.
Este es un síntoma de la mentalidad habitual de su organización. Si habitualmente tiene "tareas no programadas", entonces debe incluirlas en sus estimaciones o definir un proceso estándar para administrar dichas tareas fuera del cronograma del proyecto. Un gerente de proyecto no puede administrar tareas que no están programadas, no reportadas o no contabilizadas.
Si bien un buen gerente de proyecto se asegurará de que haya suficiente tiempo libre en el proceso para manejar las variaciones de rutina, el trabajo invisible (por definición) no se contabiliza ni se administra. El hecho de que su organización no haga esta distinción es un "olor de proceso" que indica que algo está fundamentalmente roto; Esperar que un PM sea responsable de los resultados de un proceso roto sin empoderar ni al PM ni al equipo para adaptar el proceso es una receta para el fracaso.
Hay una serie de cosas que deberían suceder en este punto. Para empezar:
Este diálogo es simplemente el comienzo de la ingeniería de procesos que debe llevarse a cabo. Echar la culpa por "las cosas como son" no debería ser el objetivo aquí; el objetivo debe ser la mejora continua del proceso.
No creo que describa necesariamente a su PM como 'demasiado entusiasta'. El PM ha tratado de instigar un sistema en una organización que usted acepta que faltaba en este sentido. El sistema claramente tiene sus problemas, que, de nuevo, usted dice que el primer ministro ha aceptado.
Lo que sugiero es que todo el equipo (pero particularmente el PM y el líder técnico) trabajen juntos para comprender qué funciona y qué no funciona en el sistema actual y hacer los cambios correspondientes. En última instancia, la responsabilidad del PM es asegurarse de que los proyectos se completen a tiempo y cumplan con los requisitos de sus clientes. Si el PM falla constantemente en asignar tareas a la persona correcta, entonces el trabajo no se está completando de manera eficiente; esta es un área clara para mejorar.
El alcance y la gama de responsabilidades de un PM pueden variar enormemente de una organización a otra. En algunos lugares pueden terminar siendo administradores glorificados, mientras que en otros juegan un papel activo en el desarrollo de productos.
Podría considerar mirar Scrum (o alguna versión 'ligera' que pueda adaptar a las necesidades de su organización) y convertir a su PM en un gerente de producto para que se concentre en lo que el cliente quiere/necesita mientras deja el trabajo técnico. al equipo de desarrollo. Sin embargo, para que esto funcione, el equipo de desarrollo aún necesitará realizar un seguimiento de su trabajo y comprometerse a completar el trabajo a tiempo (no significa que siempre sucederá, pero les da a todos más propiedad y responsabilidad).
Si el problema subyacente es que a su equipo de desarrollo le molesta que le den plazos y tareas después de años de trabajo autónomo, entonces también debe abordar este problema. En última instancia, todo el mundo está allí para hacer un trabajo. Un enfoque inclusivo se asegurará de que el sistema que implemente funcione para todo el negocio, ¡pero prepárese para un retroceso!
Sería difícil evaluar lo que está haciendo el PM de una manera imparcial solo en función de lo que escribió. Me imagino que él también se burló de usted, y tal vez usted sea un líder tecnológico cuyo papel ahora es un poco ambiguo con el de PM.
A pesar de todas las habilidades blandas que desearía en un PM o cualquier líder, gran parte de lo que es PM se trata de controles. Para una empresa que, según usted admitió, estaba fuera de control, esta persona que ingresa e implementa cualquier tipo de método de PM probablemente sería recibida como "rechinante". El cambio es difícil.
No comentaré si estoy de acuerdo o en desacuerdo con los métodos que usted indica aquí, pero diría que vería a la organización como la causa raíz de los problemas que enfrenta ahora en comparación con lo que está haciendo este primer ministro.
Su organización necesita evolucionar. Tienes que dejar que suceda. Reducir la autoridad del primer ministro para que las cosas puedan permanecer en gran medida en el statu quo prácticamente sellará su destino.
Antes de atribuir esto a un PM demasiado entusiasta, busque las causas fundamentales. Como sugiere Willl, esta podría ser una cuestión de resistencia al cambio, derivada de que el equipo ha estado jugando con la piel de gallina durante demasiado tiempo.
También debe considerar por qué el PM ha adoptado el enfoque que tiene. ¿Así se hacían las cosas en su último trabajo? ¿Está actuando bajo la guía del MD? ¿Los líderes no están haciendo su trabajo cuando se trata de administrar los recursos?
Para resolver esto, su organización necesita aclarar los roles y responsabilidades que funcionarán para usted. Aún más importante, debe establecer expectativas de desempeño y líneas claras de responsabilidad. Es bueno decir que el PM es responsable de llevar un proyecto a tiempo/presupuesto/alcance/etc., pero si los líderes del equipo no se dan por vencidos, puede pasar por todos los PM del mundo y no obtendrá Mejores resultados.
Mi opinión sobre esto es que el PM está tratando de establecer un sentido de disciplina en una empresa que anteriormente ha tenido una actitud de "despreocupación". No creo que esté siendo demasiado celoso, pero tal vez su método no sea apropiado.
Para mí, el papel del PM debe ser saber qué se debe hacer, saber si se mantiene el objetivo y comprender y gestionar los riesgos en torno al proyecto. También habrá otros deberes, probablemente en torno a la financiación de proyectos y la presentación de informes de gestión, y un PM efectivo ciertamente ayudará al resto de la organización al manejar ese lado del trabajo, permitiéndoles concentrarse en lo que mejor saben hacer.
Usted pregunta sobre las funciones del PM frente al líder técnico: suponiendo que el líder tecnológico administre a los desarrolladores, no esperaría que el PM se comunique directamente con los desarrolladores; ese debería ser el rol del líder tecnológico. El líder técnico debe, por supuesto, poder explicar qué progreso se ha logrado en cualquier momento, pero también debe tener la autonomía para asignar el trabajo según corresponda dentro de su equipo. En cuanto a la asignación de trabajo a otros, sugeriría que el PM discuta esto con el individuo en lugar de imponer sus propios pensamientos.
Me pregunto si el problema es el nivel de control que se impone o si son los medios para imponerlo. En una empresa pequeña como la que usted describe, un correo electrónico diario hacia y desde el PM suena muy burocrático e impersonal. Preferiría manejar la comunicación cara a cara, porque esto permite que tenga lugar una conversación en lugar de simplemente transmitir hechos y cifras.
También sugeriría que la frecuencia de contacto quizás debería ser diferente dependiendo de los niveles de confianza y la naturaleza de lo que hace cada persona. Si una tarea tomará una semana, un punto de control a mitad de semana puede ser apropiado, pero un control diario puede ser demasiado frecuente. Por otro lado, para tareas que solo duran unas pocas horas, una revisión diaria puede estar bien. ¡Caballos de carreras!
En resumen, entonces, se siente como si el PM estuviera tratando de imponer disciplinas y tomar decisiones por las razones correctas, pero no está usando la comunicación interpersonal adecuada para lograr los resultados deseados. Haz que hable más con la gente y bájate de su pedestal. Pero el resto del equipo también necesita cambiar, y reconocer y aceptar la autoridad que supuestamente se le otorgó cuando fue nombrado.