¿Cuáles son los mejores métodos para la gestión de proyectos en un entorno altamente incierto?

Como reconoce, los reveses y los fracasos son inevitables en los verdaderos proyectos de I + D. Existen varios sistemas de cronograma y planificación que son útiles, pero elegir uno es uno de los trabajos menos importantes como gerente de I + D.

Lo importante es que usted forme un equipo que pueda fallar productivamente: un grupo que reconoce rápidamente cuando algo no está funcionando y puede seguir adelante sin lágrimas o recriminaciones.

Para fallar productivamente, su equipo debe confiar en usted y confiar el uno en el otro. Cuando las cosas salen mal, como lo harán, nadie puede tener miedo de admitirlo, y nadie puede tener miedo de señalar problemas por miedo a ofender. Esto lo incluye especialmente a usted, el líder del equipo. Debe admitir fácilmente los errores y aceptar las críticas. Debe alabar nuevas ideas y un gran esfuerzo, y acortar cualquier ataque personal. Debe atraer a los miembros callados de su equipo y no dejar que los más ruidosos y seguros de sí mismos dominen la conversación. Debe hacer creer a todos los miembros de su equipo (porque es cierto) que su trabajo es ayudarlos a tener éxito, no atrapar y castigar sus fracasos.

Dwight Eisenhower dijo que “los planes son inútiles, pero la planificación es esencial”. El proceso de planificación, independientemente del sistema que utilice, señalará algunos problemas y dependencias que deberá conocer y evitará algunos errores evitables. No evitará fallas y contratiempos, pero lo preparará para adaptarse a ellos. Al final, sin embargo, es mucho más probable que tenga éxito con un equipo fuerte y un plan débil que con un plan fuerte y un equipo débil. Dirige tus esfuerzos en consecuencia.

Las técnicas ágiles utilizadas por la industria del software pueden funcionar bastante bien.
Comenzaría con el Manifiesto para el desarrollo de software ágil antes de analizar la historia (pre-software) del desarrollo de Scrum.

Es probable que la desviación clave del “scrum” clásico sea la falta de un equipo multifuncional, ya que la investigación tiende a requerir habilidades “profundas” (doctorado, postdoctorado, años de experiencia) que son muy difíciles de replicar.

Con los proyectos de investigación, tendemos a necesitar cierto grado de “confusión” en las etapas iniciales; También hemos encontrado que es muy beneficioso no asignar * todo * el tiempo al ciclo Scrum, pero permitir a los investigadores aproximadamente el 20% del tiempo simplemente “hacer algo útil”.

Scrum es fuerte en la entrega de proyectos, pero débil en innovación; nuestra innovación ocurre en gran medida en ese 20%.

Es importante elegir un ciclo de iteración que coincida con el ritmo natural de su equipo; el software tiende a funcionar durante ciclos de 1-2 semanas, pero sospecho que puede encontrar que 4 semanas es mejor para la investigación, especialmente si necesita profundizar bastante

Estime las tareas relativamente y luego repítalas cuando reciba comentarios.

Si usa una serie de factores (por ejemplo, complejidad, riesgo, repetición, etc.) para medir cuánto tiempo llevarán las tareas desconocidas en relación con otras tareas, tendrá una mejor indicación de cuánto tiempo tomarán, ya que en oposición al uso de estimaciones absolutas (por ejemplo, horas).


Por ejemplo, si la tarea de 10 puntos tarda 20 horas en completarse, entonces sabe que una tarea de 30 puntos debería tardar alrededor de 60 horas en completarse.

Sin embargo, es importante tener en cuenta que esta es una regla general , más que una fórmula.

Usando esta mentalidad, a medida que se desconocen más conocimientos , las tareas restantes en el proyecto se pueden predecir con mayor precisión. Por lo tanto, el tiempo restante para completar el proyecto se puede predecir con mayor precisión.

Sin saber mucho sobre el proyecto específico, porque cada uno podría ser caso por caso:

Entregables incrementales: establezca hitos para discutir si continuar con la financiación, aumentar el alcance, aumentar el personal o incluso si el proyecto no debe continuar.

Los objetivos pequeños y realistas son la única forma que conozco de abordar algo que sabe que crecerá. Debe medirlo con frecuencia y juzgar si aún es viable y rentable / valioso.

Directamente, el simple Scrum de vainilla lo reparará.
Scrum Training Agile Training de ScrumMaster Mike Cohn
Cumplir con las reglas, hacer cada paso y serás una persona / equipo cambiado en 9 semanas.