Como cada proyecto de software tiene su equipo que trabaja en él, este equipo se considera de alguna manera un "cuerpo separado" dentro de la empresa. Los miembros del equipo tienen sus asignaciones, su visión y expectativas del proyecto.
Por supuesto, surgen varias preguntas durante el proyecto, tanto técnicas como no técnicas. Las preguntas técnicas suelen ser más fáciles de resolver, ya que contamos con líderes de equipo y líderes técnicos.
Para problemas no técnicos, contamos con jefes de proyecto. Los gerentes de proyecto deben abordar todas las preguntas dentro de un equipo, desde vacaciones no planificadas hasta disputas entre los miembros del equipo.
Recientemente, un miembro del equipo quería darle sus tareas a otra persona que no está en el equipo; Yo no permití eso. Un segundo miembro del equipo retrasa constantemente el inicio de su trabajo. Otro está tratando de usar una herramienta de terceros para escribir código HTML más fácilmente. Uno de los trabajadores quiere usar su propia herramienta escrita en node.js para facilitar su trabajo, aunque esa no es una tecnología usada en nuestra empresa y nadie podría apoyar el proyecto después.
Otros PM en la empresa sin duda abordarán todas estas preguntas con el CEO, pero creo que un PM debe tener el nivel adecuado de independencia para tomar decisiones como quién debe hacer qué y cómo .
Entonces, ¿hasta qué punto los PM pueden tomar decisiones independientes?
La "independencia" no es el problema; el problema es la responsabilidad y su integridad.
La independencia es un camino al fracaso del proyecto. Eres interdependiente; su éxito está estrechamente relacionado con el de su equipo de proyecto, y el de ellos con el suyo. Cualquier otro punto de vista te llevará al desastre. Yo diría que ninguno de los problemas que enumera en su pregunta son problemas para el primer ministro.
La cuestión central es ante quién es responsable y por qué. Afortunadamente, eso es relativamente sencillo. Usted es responsable ante las partes interesadas del proyecto. El PM (debería haber) firmado el acta de constitución del proyecto; al hacerlo, se comprometió a ofrecer un alcance específico en un momento específico para un presupuesto específico.
En un mundo ideal, harías eso. En el mundo real, si la gestión de proyectos fuera tan simple, no sería una profesión remunerada.
En el mundo real, su firma en el acta de constitución del proyecto lo compromete a entregar el alcance en el cronograma del presupuesto y administrar cualquier cambio .
@Saakyan me pide que aclare "para qué"; una pregunta razonable.
Soy responsable ante mis partes interesadas de una estimación realista de si el proyecto alcanzará el objetivo. Lo ideal sería expresar mi estimación en un contexto de riesgo: "Creo que es un 90 % probable que entreguemos a tiempo y que el cliente acepte el entregable final. Tengo menos confianza en el presupuesto; es solo un 75 % probable que llegaremos dentro del 10% de nuestra estimación".
Soy responsable ante mis partes interesadas de que si hay problemas que amenazan el alcance, el cronograma, la calidad o el presupuesto, trabajaré con las partes interesadas internas para encontrar soluciones. Tenga en cuenta que soy responsable tanto ante mis partes interesadas internas/miembros del equipo como ante mis partes interesadas externas (clientes, gerencia, familias, etc.) Le debo a mi equipo trabajar con ellos para encontrar la mejor solución (la más efectiva, la menos dolorosa). ).
Soy responsable de todo eso si el alcance/programa/presupuesto cambia, presento una solución para ese cambio y un costo real para ese cambio.
El éxito implica analizar esos factores y trabajar con el equipo del proyecto para desarrollar alternativas para mitigar los efectos de lo desconocido. En su caso, también está obligado a informar a las partes interesadas.
Los proyectos existen dentro del contexto de una estructura organizativa existente, se gestionan a través de la autoridad delegada y no deben ejecutarse como feudos independientes. Todas sus subpreguntas se reducen a una falla organizacional para organizar adecuadamente el proyecto y definir el alcance de la autoridad del gerente del proyecto (si corresponde).
Además de las fallas del proceso, parece que carece de influencia tanto con su equipo de gestión como con los miembros de su proyecto. Independientemente de las razones de esto, debe solucionar los problemas (si puede) o abandonar el proyecto. Es poco probable que su proyecto tenga éxito bajo el statu quo.
Independientemente del marco, todos los proyectos requieren algún tipo de documento inicial. Esto generalmente se llama el acta de constitución del proyecto . Un buen acta de constitución del proyecto también debe definir los roles del proyecto , que incluyen:
El gerente del proyecto a menudo no es un gerente o una figura de autoridad en el sentido tradicional, y en algunos proyectos puede tener responsabilidades sin personal delegado o autoridad presupuestaria. Esta es una decisión organizacional , y una que su organización actual no ha tomado o la ha tomado de una manera con la que no está de acuerdo.
La autoridad siempre debe ser delegada desde la parte superior de una organización. Esta delegación es a menudo una cadena en la que el director del proyecto deriva cualquier autoridad que tenga (si la tiene) del acta de constitución del proyecto o del patrocinador del proyecto.
Si no se le ha otorgado ninguna autoridad, entonces debe usar la influencia en lugar de un estilo de comando y control para administrar sus proyectos. Según su descripción, parece que actualmente carece de autoridad e influencia. Es posible que desee discutir estos problemas con la persona a la que informa.
Usted trabaja para la empresa y cualquier autoridad que tenga es delegada por la alta gerencia. Por lo tanto, cuando usted pregunta:
[¿Qué] pasa si el CEO interviene y anula sus decisiones?
parece probable que una o más de las siguientes afirmaciones sean verdaderas:
Si bien a menudo es preferible que el equipo de alta gerencia trabaje a través del liderazgo designado de un proyecto para administrar un proyecto, ciertamente no es obligatorio. Independientemente de cómo se sienta acerca de sus decisiones, siempre depende de la alta dirección determinar cómo quieren que se ejecute un proyecto o equipo.
Si encuentra que su estilo de gestión de proyectos no se adapta bien a su organización, o que carece de la influencia o la delicadeza para gestionar los aspectos políticos del proyecto, entonces puede considerar buscar un rol diferente dentro de su empresa, o incluso tratando de encontrar otra empresa en la que su estilo de gestión de proyectos se ajuste mejor a la cultura de la empresa.
El único poder real que tienes que no te es delegado es el derecho a "votar con los pies". Arregle el proceso si puede, arregle su actitud si no puede... o simplemente siga adelante. ¡Buena suerte!
Como señaló @CodeGnome, no debe intentar ejecutar su proyecto como un feudo independiente.
Por otro lado, tampoco debe referir cada decisión a la cadena.
Idealmente, como gerente de proyecto (o para el caso, cualquier gerente), debe tomar todas las decisiones necesarias para ejecutar su proyecto con éxito, dentro del amplio marco de políticas establecido por el liderazgo. Sin embargo, a veces surgen problemas que pueden tener un impacto más amplio, más allá de su proyecto. Si no hay una política establecida o una dirección sobre cómo manejarlo, es posible que desee remitirlo al liderazgo superior. Incluso en tal caso, si yo fuera usted, consultaré a mis compañeros y haré una recomendación específica al director ejecutivo.
Todd A. Jacobs