Ley de la gestión de proyectos

En la lucha que mantengo con mi propia procrastinación, y que voy perdiendo claramente, este fin de semana he conseguido escuchar algunos  de los podcast que tenía cargados en el iPod desde hace algún tiempo sobre project management.

Aunque el número y calidad de los podcast que se pueden encontrar en internet sobre proyectos han aumentado de forma espectacular, preferí escuchar  los que los autores de “Manager Tools”, Mark Horstman y Mike Auzenne, dedicaron hace algún tiempo a la gestión de proyectos. Me llamó la atención que las reflexiones sobre la disciplina las realizan bajo la óptica de un directivo y no bajo la visión de un project manager.

Con el título de “La ley Horstman sobre la gestión de proyectos” los autores explican en cuatro podcast de 30 minutos su visión de la dirección de proyectos y dan consejos acerca de cómo gestionar un proyecto. Al igual que en todas sus aportaciones en el resto de  podcast sus  consejos son eminentemente prácticos.

Su exposición se basa en lo que llaman la ley Horstman:

¿Quién hace qué? Y ¿Cuándo?

y que se ha de cumplir cuando se está gestionando un proyecto.

El concepto que hay detrás de esta ley es muy sencillo, aunque a veces lo olvidemos o nos abrume la complejidad del mismo, todos los proyectos son al final un conjunto de tareas sencillas que han de ser realizadas por personas en un marco temporal dado. Por tanto gestionar el proyecto ha de pasar por asignar responsables de las tareas, detallar de qué son responsables y cuándo han de finalizar la tarea.

Como dicen los autores en el audio, un bosque no es más que un conjunto de árboles y si quieres realizar una actuación en el bosque tienes que pensar lo que vas a hacer en cada uno de los árboles.

Aunque no comparto completamente su enfoque ya que está muy orientado a la ejecución,  he de reconocer que me gusta su simplicidad y su planteamiento.

¿Qué os parece?

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

About the author  ⁄ Alberto García

4 Comments

  • Responder
    David Cano
    7 junio, 2010

    En alguno de los proyectos que he participado hemos utilizado la matriz de responsabilidades con las siguientes definiciones:

    RESPONSABLE. Autoridad para aprobar. Aceptación final del resultado de esa actividad. Toma decisiones.
    E EJECUTOR. Responsabilidad sobre la ejecución de la tarea. Stakeholder responsable de que se haga el trabajo. No tiene por qué ser quién
    tome las decisiones, pero si que conduce al equipo para que se realice el trabajo dentro del tiempo asignado a la tarea.
    C CONSULTADO. Debe ser consultado. Este stakeholder proporciona información necesaria para la realización del trabajo. No es quién toma
    las decisiones, pero debe ser consultado para que la pueda proporcionar antes de tomarlas.
    I INFORMADO. Debe ser informado de que la tarea va a realizarse. Le interesa tener información actualizada sobre el progreso de esa tarea.

    La realidad que he percibido es que es un documento que normalmente no se utiliza, a no ser que exista algun tipo de conflicto, que en tal caso, al haberlo aprobado anteriormente por todas las partes interesadas, sirve como herramienta para mejorar la coordinación y obligaciones entre los participantes del proyecto.

    Estoy de acuerdo en simplicar al máximo la manera de identificar responsabilidades, independientemente del tamaño del proyecto.

    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  • Responder
    Albert Cubeles Author
    6 junio, 2010

    Gracias por el comentario. La asignación de roles y responsabilidades en proyectos de cierta envergadura necesita de herramientas especificas como la que mencionas o como las conocidas como RACI.

    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
  • Responder
    Albert peguera
    6 junio, 2010

    En este diagrama de responsabilidades creo que es importante tener claro qué tipo de acción se va a realizar por este agente que interviene en el proyecto. Yo divido las acciones en:
    - Informa
    - Ejecuta
    - Colabora
    - Aprueba
    Quizás parece demasiado genérico, pero cuando tienes 5000 procesos diferentes de un proyecto (árboles del bosque) es importante tener un cuadro general de los procesos dividido (de momento) en estos 4 estados sin llegar al detalle extremo. Precisamente cuando el detalle es minucioso, el sistema deja de ser efectivo.

    VA:F [1.9.22_1171]
    Rating: 0 (from 0 votes)