Categoría: Gestión de proyectos

Preguntas clave para iniciar la gestión de un proyecto

En un “mundo ideal” y mientras sea posible, en la gestión de un proyecto, preferentemente al comenzar, nos deberíamos plantearnos las siguientes preguntas:


En un “mundo ideal” y mientras sea posible, en la gestión de un proyecto, preferentemente al comenzar, nos deberíamos plantearnos las siguientes preguntas:

  • Formulación del problema: ¿Cuál es el problema?, ¿Por qué es un problema?
  • Misión del proyecto: ¿cuál es el propósito de este proyecto?
  • Objetivos del proyecto: ¿Cómo podríamos descomponer los objetivos en elementos específicos, mensurables y justificables?
  • Estrategia del proyecto: ¿Cómo pensamos resolver el problema? o ¿cómo pensamos aprovechar la oportunidad?
  • Requisitos: ¿Cuáles son los resultados detallados que produce el proyecto?
  • Criterios de éxito: ¿Qué debe suceder para que el patrocinador, cliente y público interesado declaren que este proyecto ha sido un éxito? o ¿Qué valor de negocio estamos obteniendo de este proyecto?
  • Alcance del proyecto: ¿Qué conseguirá el proyecto? o ¿Qué no conseguirá el proyecto?
  • Resultados: ¿Qué resultados tangibles estamos produciendo y demuestran que se esán los criterios de alcance?
  • Riesgos: ¿Qué eventualidades podrían afectar al éxito del proyecto?, ¿Cuál es su probabilidad?, ¿cuál sería el impacto?, ¿Cómo podríamos responder?
  • Suposiciones: ¿Qué no sabemos todavía y qué suposiciones debemos hacer para decidir que la planificación siga adelante?
  • Limitaciones: ¿Qué limitaciones se oponen a la realización de este proyecto?

Tener claras las respuestas de estos temas, nos ayudará a realizar una mejor gestión

Referencia: ISBN 978-84-415-3225-0

Análisis de los riesgos de un proyecto

Identificados y clasificados los riesgos que pueden amenazar un proyecto, el siguiente paso es analizarlos. Debido que la lista de riesgos podría ser amplia y no sería fácil realizar un seguimiento a todos ellos, se debe identificar aquellos riesgos que requieren una atención especial. Para facilitar este análisis el equipo del proyecto puede plantearse dos preguntas:


Identificados y clasificados los riesgos que pueden amenazar un proyecto, el siguiente paso es analizarlos.  Debido que la lista de riesgos podría ser amplia y no sería fácil realizar un seguimiento a todos ellos, se debe identificar aquellos riesgos que requieren una atención especial.  Para facilitar este análisis el equipo del proyecto puede plantearse dos preguntas:

  • ¿qué posibilidad existe que un riesgo se materialice?
  • y si esto ocurre, ¿qué impacto negativo tendría en el desarrollo del proyecto?

Las respuestas obtenidas se podrían ubicar dentro de una matriz 3 x3 para analizar el impacto vs. Probabilidad de cada riesgo.  En la matriz propuesta se estiman tres niveles (bajo, medio y alto), pero dependiendo de las características del proyecto, quizás sería necesario ampliar el número de respuestas (por ejemplo: bajo, medio bajo, medio, medio alto, alto).  Los riesgos identificados con alta probabilidad y alto impacto deberán tener un tratamiento especial y el equipo de proyecto debe estar preparado para brindar una respuesta inmediata si estos se concretaran.

Referencia: ISBN 978-84-415-3225-0

Clasificación de los riesgos de un proyecto

Identificados los probables riesgos que podrían surgir en forma de problemas en la ejecución de un proyecto (ver post anterior), deberíamos clasificar los riesgos identificados. El documento de referencia nos sugiere una clasificación que facilite la comprensión en base a las siguientes categorías:


Identificados los riesgos que podrían surgir en forma de problemas en la ejecución de un proyecto (ver post anterior), a continuación, deberíamos clasificar los riesgos identificados.  El documento de referencia nos sugiere una clasificación que facilite la comprensión en base a las siguientes categorías:

  • Riesgos Técnicos
  • Riesgos Externos
  • Riesgos Organizativos
  • Riesgos de gestión del proyecto

Estas categorías podrían ser subdivididas del siguiente modo:

Adicionalmente, en cada riesgo identificado se debería señalar a que aspecto(s) del proyecto afecta (factores impulsores del proyecto):

  • Alcance
  • Calendario
  • Presupuesto
  • Recursos
  • Calidad

Referencia: ISBN 978-84-415-3225-0

Identificación de los riesgos de un proyecto

Ningún proyecto de implementación de cualquier tecnología se escapa de los contratiempos, pero la probabilidad que estos ocurran y las consecuencias que podrían causar, en muchas ocasiones son previsibles. Esta posibilidad que algo ocurra y genere incertidumbre, es decir la posibilidad que algo “inesperado” tenga lugar y que ocasione el incumplimiento de otras cosas, se denomina riesgo. Por ejemplo: Se utilizará un producto que incluye “recientes avances” de un uso práctico y real muy bajo (seguro que conlleva riesgos).


Ningún proyecto de implementación de cualquier tecnología se escapa de los contratiempos, pero la probabilidad que estos ocurran y las consecuencias que podrían causar, en muchas ocasiones son previsibles.  Esta posibilidad que algo ocurra y genere incertidumbre, es decir la posibilidad que algo “inesperado” tenga lugar y que ocasione el incumplimiento de otras cosas, se denomina riesgo.  Por ejemplo: Se utilizará un producto que incluye “recientes avances” de un uso práctico y real muy bajo (seguro que conlleva riesgos).

Para controlar estas situaciones “inesperadas” es necesario definir un plan de gestión de riesgos, el primer paso es identificar con antelación los riesgos a los que se enfrenta el proyecto.  Usando técnicas como la de “tormenta de ideas” son útiles para detectar los riesgos de un proyecto, pero además se debería contemplar las siguientes vías:

  • Revisar la estructura desglosada de tareas. Hay funciones y tareas de negocio críticas que nunca antes se han realizado que tienden a incrementar los riesgos.
  • Revisar lecciones aprendidas de proyectos similares.
  • Reuniones con expertos.
  • Diagramar las tareas del proyecto (diagrama de causas y efectos) para facilitar el análisis el uso del tiempo y los recursos.
  • Realizar un análisis DAFO (debilidades, amenazas, fortalezas y oportunidades).

Referencia: PMP Notes

Para el desarrollo de sistemas, ¿la metodología en cascada debería evitarse?

A muchos de nosotros nos puede resultar familiar llegar a la puesta en marcha de un nuevo sistema o aplicación informática para darnos cuenta que algo no funciona como se esperaba, ya sea porque no se comprendió lo que se solicitaba o porque al realizar el desarrollo técnico se encontró una “limitación” de la herramienta informática. Esta situación, en gran medida, es por la metodología de desarrollo que se ha optado.


A muchos de nosotros nos puede resultar familiar llegar a la puesta en marcha de un nuevo sistema o aplicación informática para darnos cuenta que algo no funciona como se esperaba, ya sea porque no se comprendió lo que se solicitaba o porque al realizar el desarrollo técnico se encontró una “limitación” de la herramienta informática. Esta situación, en gran medida, es por la metodología de desarrollo que se ha optado.

En la actualidad, muchos proyectos siguen la metodología de las fases Análisis, Diseño, Construcción, Implantación y Mantenimiento.  Una metodología, con fases rígidas, formales, siguiendo un orden riguroso, secuencial, empezando la siguiente fase cuando ha culminado la anterior. Una metodología clásica, sino nos equivocamos, de más de 30 años, tiempos en que todo tenían un ritmo más pausado, muy distintos a los tiempos actuales que exigen más rapidez y flexibilidad.

El documento de referencia señala muy bien cuando podría ser útil la metodología clásica (también denominada en cascada):

“… este tipo de metodologías sólo se usa para el desarrollo de sistemas muy grandes que requieren gran formalización  y los requerimientos son fácilmente reconocibles”

Y se señala las siguientes limitaciones de esta metodología:

  • Dificultad para eliminar errores
  • Falta de flexibilidad, el cual incrementa los costes y duración del proyecto.

Los fallos más comunes o triviales se detectan al comienzo, mientras que los más graves se detectan a la implantación, volviendo a ser necesario a analizar, diseñar y construir aquello que estaba mal implantado… ¡y comienza el caos!

Referencia: ISBN 978-84-7356-814-2