¿Cómo se cierra la brecha en la producción de entregables entre operaciones y proyectos?

Al igual que con la mayoría de las organizaciones de tamaño razonable, la organización actual tiene un equipo operativo y un equipo de proyecto que impulsan diversos grados de iniciativas.

A diferencia de cualquier otra organización para la que he trabajado, hay muy poca comprensión de los entregables de los que cada equipo es responsable y que tienen relación con la próxima iniciativa. Por ejemplo, hay una batalla constante entre los equipos con respecto a la propiedad de la documentación. Cuando se inicia un proyecto, hay muy poco por medio de la comprensión del estado actual. Se le dice al proyecto que ponga al día toda la documentación relativa a dicha iniciativa. Esto sucede rara vez ya que el equipo del proyecto no considera que sea su responsabilidad actualizar la documentación operativa que debería proporcionar suficiente información sobre el estado actual.

Me siento entre estos equipos y estoy tratando de cerrar la brecha, sin embargo, no estoy seguro de cuál es la mejor manera de hacerlo, ya que hay mucha controversia histórica. Siendo el chico nuevo en el bloque, me gustaría cerrar esta brecha. Intentar que los equipos compartan un objetivo común no ha tenido éxito ni ha sido abierto sobre problemas e inquietudes específicos. Esto a menudo lleva a señalar con el dedo y profundiza aún más las relaciones ya agrias.

¿Hay alguna metodología específica que pueda adoptar y adaptar, ya que imagino que la situación es un tema común en varias organizaciones de todo el mundo?

EDITAR

Para ayudar a responder la pregunta planteada por Tobias

Rol: El rol que juego es el de Arquitecto Empresarial. El desafío clave que tengo es que no hay consistencia en los estándares, la información y el conocimiento son tácitos y las personas no están dispuestas a compartir información.

Los equipos incluyen gerentes de proyecto, analistas comerciales, servidor y administración, redes y mesa de ayuda. Todos los demás roles son compatibles con los proveedores.

¿Podría proporcionar algunos detalles más: ¿Cuál es su función, por ejemplo, desarrollador, PM? ¿Qué tipo de equipos existen? ¿Cuál es el trabajo de los equipos: desarrollo de diferentes funciones, desarrollo y control de calidad?
@Tobias: actualicé mi pregunta con respuestas a sus preguntas.

Respuestas (2)

En primer lugar, observe que su empresa es (probablemente) exitosa, de lo contrario no la habría elegido para su nuevo trabajo. No digo que todo sea perfecto, pero tenga cuidado de ser el nuevo diciéndole a los viejos cómo hacer el trabajo. Mi primer punto es:

Plantea preguntas abiertas. Como estas...? ¿Cuál es la motivación detrás de...?

Tal vez haya una imagen más grande que cause los problemas que resolviste pero que traiga un beneficio mucho mayor en otro lugar.

Por supuesto, debe trabajar en la mejora de los procesos y el trabajo en equipo. El responsable de los problemas dentro del proyecto es el PM. Verifique el plan del proyecto, esp. la parte de gestión de riesgos y comunicaciones. Supongo que se le pide a cada miembro del proyecto que plantee los riesgos comunicándolos al PM. Ayude al PM haciéndolo. Digamos que identificó un riesgo dentro de su campo de responsabilidad y lo redujo al cronograma y presupuesto. Proporcione también una probabilidad de riesgo. Debe ser la motivación del PM para llegar a la causa raíz del riesgo, si comparte su punto de vista sobre el riesgo. Si no, pida una explicación, usted es el nuevo y está dispuesto a aprender.

Por cierto, con una buena WBS y una gestión de proyectos que funcione , esos problemas no deberían existir (o al menos no ser un problema tan grande).

Si su PM no puede o no está dispuesto a trabajar en el riesgo, o si culpa a los procesos de la organización, pase a los chicos de mejora de procesos . Dado que trabaja para una empresa más grande, habrá alguien (generalmente dentro de QA) responsable de la mejora del proceso. El enfoque es bastante similar al de acercarse al PM: cambie de riesgos a oportunidades en su formulación.

Dependiendo de la definición de éxito, la compañía se desempeña financieramente muy bien. Sin embargo, en mi opinión, esto se debe principalmente a que tiene un estado cercano al monopolio. Por ejemplo, no tiene sentido abrir otro muelle ya que el titular principal cumple bien el rol. Debería haber elaborado la pregunta, así que mis disculpas. Hay una serie de problemas además de la falta de comunicación, propiedad y responsabilidad.
Dado que la mayoría de ellos han estado allí durante años, por ejemplo, cerca de 30, la introducción de cambios adaptativos es difícil de implementar. Tuve que fighttrabajar con uñas y dientes para poner en marcha algunas estructuras básicas, por ejemplo, funciones de gobierno, riesgo y auditoría, etc.
Esperaría una función de mejora de procesos, sin embargo, no existe, por lo tanto, el limbo. En cuanto a una visión más amplia, estoy viendo esto desde una perspectiva empresarial. Las unidades de negocios no confían en el brazo de entrega ni en el equipo del proyecto y, por lo tanto, encuentran formas de navegar alrededor de ellos. He tenido que sentarme con las partes interesadas clave responsables de una serie de áreas con los dueños de negocios para poder facilitar la comunicación y un entendimiento común.
Lo que describes exige una nueva orientación de la organización en cuanto a procesos y estructura organizativa. Google/busca proceso de cambio y CMMI ...

Bienvenido a StackExchange - Gestión de proyectos.

Este no es un problema poco común en las grandes empresas. La propiedad clara de los entregables puede ser un desafío. Dado que eres nuevo, probablemente estés en una buena posición para hacer algo al respecto, si andas con cuidado. Recomendaría un enfoque de dos fases.

Paso 1-Llevar a cabo entrevistas con las partes interesadas: he utilizado este método durante varios años con gran efecto. Mi nuevo empleador utiliza una variación en todos sus compromisos de consultoría, con un efecto igualmente alto. A un alto nivel (realmente debería escribir un blog sobre esto): - Identifique a todas sus partes interesadas y clientes clave. Esto puede ser fácilmente más de 20. Si llega a 50, comience a buscar a las personas clave en estos grupos. - Solicitar 30 minutos de su tiempo. Haga esto persona por persona, no envíe un correo electrónico masivo. La solicitud debe incluir la diapositiva PPT y las preguntas a continuación. - Crea una diapositiva (¡solo 1!) de PowerPoint. La diapositiva debe tener la misión/visión de su organización (invéntela si es necesario, pero deje que su jefe la revise), un resumen de su plan de 90 días y una línea con "¿Por qué estoy aquí?". - El plan de 90 días debería ser algo así como "Escuchar", "

Las entrevistas funcionan de dos maneras muy poderosas. La primera es que construyen confianza y relaciones. Casi nada es más poderoso que preguntarle a la gente qué es lo que necesita y quiere. La segunda es que al hacer las mismas preguntas a todos, puede crear datos cuantitativos a partir de las entrevistas cualitativas.

Paso 2 : cree una matriz de responsabilidad Es casi seguro que saldrá de las entrevistas con datos sobre la confusión de responsabilidades (pista, es posible que desee elaborar una pregunta específica para descubrir esto como "¿Siente que sus roles y responsabilidades son entendidos por la organización). Use estos datos y luego trabaje con su gerente y el liderazgo de estos dos grupos para identificar esto. Sugiera armar una Matriz de Responsabilidad. Prefiero el RASCI completo sobre el RACI. Haga una hoja de cálculo. Cree columnas para "Responsable, Responsable, solidario, consultado, informado." Google RASCI para obtener más información sobre esto. Los dos claves son responsable y responsable. La persona responsable hace el trabajo, en el desarrollo tradicional, la persona responsable a menudo se encuentra más arriba en la cadena alimenticia de esa persona.

Probablemente terminará con agujeros en la matriz y lugares donde hay conflicto sobre quién hace qué. Desde aquí, programe reuniones y resuélvalo.

Si tiene alguna pregunta, no dude en ponerse en contacto conmigo directamente.

Mis seis preguntas: 1- ¿Qué necesitan y esperan usted y su organización de mi organización? 2- ¿Qué métricas usa/usará para evaluarnos? 3‐ ¿Cómo nos ha ido en relación con sus necesidades, en el pasado? 4‐ ¿Cuál es su percepción de nuestra organización en general, que tal vez los números no se muestran? 5‐ ¿Qué comentarios y/u orientación tiene para mí/mi rol/mi equipo? 6- ¿Cuáles son tus mayores puntos débiles?

Gracias Joel. El mayor desafío que tengo, aunque he intentado tener conversaciones, es el estándar en el que se deben producir los entregables. Por ejemplo, si se trata de un diseño técnico, esto actualmente varía ya que la mayor parte del trabajo lo completan diferentes proveedores y, en algunos casos, el mismo proveedor pero diferentes personas. En todos los casos, no hay coherencia. Nadie parece saber cuánto debe ser cada uno de estos documentos. ¿Cómo recomendaría abordar este tema?
Sinceramente, vería la posibilidad de implementar un modelo de gobernanza Lean/Agile desde la cartera hasta los equipos de entrega. No tengo la costumbre de proxenetismo de las empresas para las que trabajo. Dicho esto, parte del motivo por el que me uní donde estoy ahora es que tienen un modelo sólido para pasar del caos empresarial a modelos de entrega predecibles y más allá. El corazón de esto es Claridad en el Backlog (Requisitos) y formar equipos dedicados y multifuncionales de la manera correcta. Puede hacerse una idea de esto en esta presentación de diapositivas: tinyurl.com/lek2cy8 (Por qué la agilidad está fallando en las grandes empresas, por Mike Cottmeyer)
No creo que el problema sea tanto una metodología. El problema parece surgir de la falta de propiedad, responsabilidad y gobernanza básica. Tuve que luchar con uñas y dientes para establecer algunos de estos, así como confrontar a varios miembros del equipo, ya que hay renuencia a adoptar prácticas que brinden resultados exitosos. La situación ha llevado a mayores costos y plazos. Intentar put things rightha aumentado los costos considerablemente ya que la base era débil al principio.
Correcto, se trata de falta de claridad, responsabilidad y trabajo terminado para medir. Recomendé el enfoque Lean/Agile ya que tiene un gran éxito en la generación de estas cosas. Se trata de ir a la base y construirla primero. Construya equipos estables y genere requisitos bien entendidos. Bien entendido significa que todo lo que se necesita para enviar al cliente se entiende y se posee.