Many organizations have decided that there is no need to choose between Agile and Waterfall aproaches to manage projects. There is a sinthesys solution than can be tested in some environments.
The project management world has followed a triad evolution, as in Hegel’s dialectical method. Waterfall was the thesis, Agile the antithesis … and now there are approaches that try to be a kind of synthesis of both models. A logical evolution.
Mixed approaches
How can agile and waterfall be combined?
There are differents approaches to achieve the convergence of both mindsets:
Agile-fall. Teams following this model try bo be agile but they keep falling into waterfall development habits. It is a way to develop a slow transition.
The Envelope method, that is supposed to help the project manager to maintain the relationship between the agile project team, the non-agile elements of the project and the rest of the enterprise.
What are the benefits of these kind of approaches?
Probably there will be people used to work in ‘pure agile’ or ‘pure waterfall’ environments who will say that these approaches are just a perversion of the core values of their project management systems.
Nevertheless I think there might be situations where these options may be valuable:
Organizations who are transitioning from waterfall to agile and vice versa and need to remain in an intermediate step for some time instead of moving directly from one environment to the other one.
Organizations where the top management is used to deal with waterfall project managers and whose development teams have found that they achieve a better performance being agile.
Complex and big projects where there is part of software development and part of hardware or infrastructure deployment.
What is your opinion? Have you tried any hybrid approach to project management? What were the results?
Do you know any other hybrid approach to project management? I would like to know more about it, please add comment with your explanation.
Como comentaba en mi último post del año pasado, uno de los motivos del posible fracaso de la utilización de Scrum en las organizaciones es el no trabajar con ‘contratos ágiles’.
Este tipo de contratos busca principalmente dotar de flexibilidad a las relaciones contractuales entre proveedor y cliente, de forma que este aspecto de la relación se alinee con la dinámica de la agilidad en la gestión de los proyectos.
Modalidades de contratos ágiles
Hay muchas modalidades de contratos que incorporan esa flexibilidad en la relación cliente-proveedor. El objetivo principal es repartir el riesgo de forma razonable entre ambas partes. La forma de hacerlo, en pocas palabras, es fijar coste y plazos de entrega y permitir flexibilidad/variabilidad en el alcance. El cliente va sabiendo conforme avanza el proyecto qué es lo que va a querer como resultado de su proyecto y el contrato debe permitir moldear el alcance conforme el proyecto avanza beneficiando a ambas partes y priorizando la entrega de valor para el cliente por encima del cumplimiento de un plan. Voy a enumerar y explicar brévemente algunos tipos de contrato ágiles que conozco:
Money for nothing, change for free; el cliente puede cancelar el proyecto en cualquier momento pagando al proveedor un porcentaje del alcance cancelado. Cualquier funcionalidad puede cambiarse por otra de igual peso.
Time and materials iterativo e incremental; entregas funcionales al final de cada sprint. Posibilidad de terminar el contrato en cualquier momento (con o sin coste).
Precio por función; incentiva la entrega de software funcional cuanto antes. Los cambios son bienvenidos si se pagan.
Puntos y velocidad; calcula puntos y velocidad. Calcula el coste del proyecto en base a horas. Reduce el precio de horas y pon el resto en precio de puntos.
Compromiso agile; target time para MoSCoW. Mínimo y máximo agresivos. Por encima del máximo el proveedor pierde, por debajo del mínimo el proveedor gana. En el medio comparten costes y beneficios al 50%.
Pues, como decía al principio, para evitar movernos en el triangulo de hierro que acostumbra a perjudicar al proveedor y entrar en una dinámica de ganar-ganar en la que ambas partes salgan beneficiadas.
¿Utilizáis contratos ágiles en vuestras organizaciones? ¿qué tipos de contratos empleáis? ¿cuáles son los resultados? ¿estáis satisfechos?
Hace algún tiempo que me pregunto si Agile y Scrum en particular son una moda o si están aquí para quedarse. En mi trabajo tengo contacto con gente de muchas empresas que desarrollan software; desde clientes a proveedores o candidatos a los que entrevisto en procesos de selección. La gran mayoría me explican que en sus respectivas empresas usan Scrum pero todos ellos puntualizan en seguida que no son talibanes de Scrum. Utilizan aquello que les es útil. No sé si eso es Scrum o si en muchos casos se pervierte el sistema y se pierden los beneficios.
Scrum es fácil de entender a nivel teórico pero más complejo de aplicar en la práctica. Y es que Agile no es para todos. No se trata simplemente de una forma de hacer las cosas por parte del equipo de desarrollo. Se precisa de un cambio organizacional importante y de equipos experimentados y técnicamente muy capaces.
– Trabajamos con contratos de precio fijo y alcance definido.
– Nuestros clientes, en general, no están interesados en comprometerse como Product Owners.
– Nuestros equipos, con frecuencia, no tienen la madurez suficiente y no se autogestionan.
– Los equipos de proyecto no son estables y sus integrantes trabajan en varios proyectos simultáneamente.
Y podría seguir con más razones.
Eso sí, en nuestras pruebas hemos descubierto cosas positivas. Los valores ‘lean’ y los tableros Kanban nos resultan muy útiles. Detectar y eliminar desperdicios (waste) además de ver todo el proceso en su conjunto nos está resultando provechoso.
Y es que, como en muchas otras disciplinas de conocimiento, la dirección de proyectos está en constante evolución. Es importante mantener una actitud abierta a los cambios, a la posibilidad de cometer errores y aprender de ellos y a la mejora constante (un valor de ‘lean’).
Estoy seguro de que en breve (si no han aparecido ya) surgirán metodologías de síntesis entre lo ágil y lo predictivo, como ya anunció hace años Juan Palacio. Y deberemos seguir experimentando y aprendiendo de forma constante y con actitud al tiempo crítica y abierta.
¿Cuál es tu opinión? ¿Qué experiencia tienes con Scrum o con otras formas de trabajo ágiles?
“A tree as great as a man’s embrace springs from a small shoot; A terrace nine stories high begins with a pile of earth; A journey of a thousand miles starts under one’s feet.”
Lao-Tse – Tao Te Ching
It is a lot easier to face a problem when it is in an early stage than when it has grown too much. So, this shows us one of the most important attributes of a good project manager: proactivity.
A project manager’s work should not focus on dealing with problems, it should focus on preventing them. We must manage the risks of a project, but how can we do it more efficiently? It is not possible to preview everything.
In my opinion, we must be prepared and have:
A system
A system, for instance, like the one explained in the PMBoK. It is necessary plan to manage risks, to identify them not only in the beginning of a project but during the project too, analyze the identified risks and develop responses. And repeat this process periodically during the life of the project.
Team support
The whole team must participate in the process of identifying risks and planning responses. They are able to help us identify possible problems that the project manager couldn’t imagine.
Communication
That takes me to the third point: good and fluent communication with the team, the client (and/or the Product Owner).
The Project Manager also must contribute to create an environment of confidence amongst the project team so that ideas, problems, risks, solutions, … flow in the team.
Everybody should feel that they can share their thoughts freely and all the important information should flow easily so that the ones who must use it to make decisions have it when they need it.
Tools
And that brings me to the final point: the tools.
We need tools to support communication, plans, assessments, … I have included them in the end because I think they are necessary but they don’t make the system. They make our life easier but they are useless if we do not have a plan and processes to systematically manage risks and we have not created an environment with the team where they feel free and motivated to communicate.
What do you think is more important? What kind of processes do you use in your projects to manage risks? Does the team always help proactively?
Please, share your comments.
Ya he hablado en este blog sobre la metodología y los principios a seguir en un proceso de implantación de un Sistema de Gestión de la Calidad (SGC) según ISO 9001.
Ahora me gustaría tratar con algo más de detalle las fases a seguir en un proyecto de este tipo. En concreto, me voy a centrar en la fase de Planificación (la P del ciclo PDCA).
Bajo mi punto de vista, los hitos más relevantes son:
1. Diagnóstico de la situación.
2. Obtención del compromiso de la Dirección con la implantación. Definición de la política de la calidad
3. Elaboración de un plan de actuación para la implantación y la certificación.
Vamos a verlos ahora con más detalle.
Diagnóstico
En esta fase es conveniente revisar la forma como se está (o no se está) gestionando actualmente la calidad en la organización.
Cuando actuamos como consultores externos, es importante dedicarle el tiempo necesario a esta fase. Se trata de comprender lo mejor posible la forma como actualmente está trabajando la organización. Hay que preguntar mucho y escuchar de forma activa, hacer participar al máximo de personas que vayan a estar afectadas por el proyecto y ser muy empático.
En esta fase, y de acuerdo con la Dirección, podremos definir el alcance más adecuado para el sistema, el tiempo que se le va a dedicar y los recursos necesarios.
Pero también, mediante el diálogo con todos los implicados, deberemos ser capaces de detectar posibles elementos de resistencia al cambio y también posibles riesgos que puedan dificultar la consecución de los objetivos del proyecto. Como consecuencia, uno de los resultados de esta fase será un listado de alto nivel de los riesgos del proyecto junto con posibles acciones a realizar en relación a ellos.
Compromiso de la Dirección
Para empezar, se debe obtener un compromiso formal de la Dirección en relación a la implantación. Ésto es básico y si no se logra es razón suficiente para no continuar con el proyecto. Uno de los primeros entregables debe ser la definición junto a la Dirección de una Política de Calidad.
También es necesario hacer un análisis de las necesidades de los clientes, establecer métodos para medir su nivel de satisfacción y planear cómo se va evaluar a proveedores (si no se estaba haciendo ya) y analizar cómo se tratan las incidencias y/o reclamaciones de los clientes.
Acabaremos esta fase fijando los objetivos de la calidad, de acuerdo con la Dirección y con los implicados en conseguirlos.
La implantación de un sistema de gestión de la calidad debe enfocarse como un proyecto. Debe tener un alcance definido, un presupuesto y un calendario.
Al igual que es fundamental obtener el compromiso de la Dirección, también es básico designar un responsable de dirigir este proyecto. Es conveniente que sea una persona de dentro de la organización, que sea buen conocedor de su cultura y de su estructura.
También es importante que este persona tenga un perfil que le permita liderar el proyecto y ser capaz de comunicarlo adecuadamente dentro de la organización. De hecho, probablemente la actividad a la que tenga que dedicar más tiempo dentro del proyecto sea la comunicación.
Es posible que internamente dispongamos de personas con este perfil pero que no tengan conocimientos sobre gestión de la calidad. Eso no es invalidante, bajo mi punto de vista. En caso de encontrarnos en esta situación será conveniente formar adecuadamente a la persona escogida y ayudarla con un consultor externo que aporte el conocimiento sobre la gestión de la calidad y la experiencia en su aplicación en otras organizaciones.
Doy por supuesto que la persona escogida está completamente comprometida con el proyecto y dispuesta a asumir el rol de agente de cambio en la organización, en complicidad con el consultor externo. Bajo mi punto de vista, tan importante es la aptitud como la actitud.
¿Qué opináis sobre la fase de planificación? ¿Cuál es vuestra experiencia al abordar este tipo de proyectos en vuestras organizaciones?
La Guía del PMBOK®, es un conjunto de buenas prácticas internacionalmente reconocido para la dirección y gestión de proyectos. La quinta edición se ha convertido en un estándar reconocido por ANSI (y publicado como anexo en la propia guía).
Elaboración conjunta PMI-IEEE
La “Extensión de Software de La Guía del PMBOK®” ha sido elaborada conjuntamente por el PMI y por la IEEE Computer Society. Se basa en 5ª edición de La Guía del PMBOK®, manteniendo su estructura, procesos y coherencia en el discurso pero incorpora elementos propios de los proyectos de desarrollo de software para adaptarse a sus características específicas como los métodos de desarrollo adaptativo, que permiten aprovecharse de la naturaleza específica del producto de estos proyectos: las aplicaciones. En general, se trata de productos que permiten la fácil y rápida elaboración de prototipos y el desarrollo incremental.
Público objetivo: todo el involucrado en proyectos de TI
Esta “Extensión” está escrita pensando en organizaciones y equipos que se enfrentan tanto a proyectos de desarrollo como de modificación o de implantación de software y cubre tanto proyectos llevados a cabo internamente como la gestión de proyectos externalizados.
Dado que hay aspectos que no varían en un proyecto de software respecto de uno cuyo producto sea distinto, en todos los apartados en los que no hay especificidades en un proyecto de software se deriva al lector al punto concreto de “La Guía del PMBOK®”.
Por el contrario, cuando hay técnicas o situaciones concretas y específicas de los proyectos de software éstas se mencionan o referencian en la propia “Extensión”. Como ejemplo, uno de mis intereses personales es la Calidad en los Proyectos. En el capítulo 8 del libro se trata este tema y se hace referencia a técnicas de SQA (Software Quality Assurance) y SQC (Software Quality Control) junto con estándares del IEEE aplicables a cada caso, como el IEEE Standard 829 (Software and System Test Documentation) o el IEEE 1008 (Unit Testing).
Habrá que ampliar la librería … (Fotografía de neoprolog bajo licencia CC BY 2.0)
¿Consideráis útil esta aproximación del PMI frente a los entornos ágiles alternativos?
¿Habéis tenido oportunidad de leer el libro? ¿Qué opináis? ¿Consideráis útil y acertada su publicación o bien pensáis que no tiene sentido adaptar “La Guía del PMBOK®” a proyectos de software disponiendo de entornos ágiles como Scrum o Kanban?
Hace unos días asistí a la presentación de una herramienta de gestión de riesgos, aplicable a la gestión de proyectos pero también a otros ámbitos.
La herramienta, a partir de las estimaciones realizadas por el director de proyecto y su equipo de colaboradores, realiza un elevado número de simulaciones (configurable) siguiendo el método de Montecarlo.
Qué es la simulación de Montecarlo
La simulación de Montecarlo consiste en crear un modelo matemático del sistema a analizar, identificando aquellas entradas o variables del modelo cuyo comportamiento aleatorio determina el comportamiento global del sistema.
Una vez identificadas las mencionadas variables aleatorias, se procede a generar –mediante una aplicación informática- muestras aleatorias (valores específicos) para estas variables y a analizar el comportamiento del sistema ante los resultados generados.
Repitiendo n veces este proceso, se obtienen n resultados sobre el comportamiento del sistema, permitiéndonos entender mejor el funcionamiento del mismo. A mayor número (n) de experimentos realizados, lógicamente, obtendremos más precisión en el análisis.
El Casino de Montecarlo dio nombre a la simulación
Cómo se aplica la simulación en la dirección de un proyecto
En nuestro caso, las variables de entrada al sistema serían, por ejemplo, las variaciones en el coste o en la duración de las actividades del proyecto en función de que se materialicen o no determinados riesgos. Como resultado, la aplicación proporciona, entre otros datos, una gráfica con las probabilidades de acabar el proyecto en determinada fecha o con un determinado coste.
Actualmente la tecnología nos puede ayudar mucho y, especialmente en proyectos de elevado coste y/o en los que no acabar en plazo pueda causar peligro para equipamientos o vidas humanas, este tipo de herramientas puede ser de gran ayuda.
El factor humano
Sin embargo, mi reflexión viene motivada porque toda la información de partida que utiliza la herramienta debe ser proporcionada por personas; la probabilidad y la estimación de impacto de que se materialice un determinado riesgo, la identificación exhaustiva de los riesgos que pueden afectar al proyecto, los criterios para definir la matriz de probabilidades e impactos … Si todo ésto no es acertado, todos los cálculos que muy afinadamente realicen las máquinas en base a esta información serán erróneos.
La experiencia del Director del Proyecto y de su equipo, su formación, la posibilidad de tener un equipo de proyectos multidisciplinar, que sea capaz de tener en cuenta todas las afectaciones e implicaciones del mismo, la posibilidad de disponer de una buena base corporativa de lecciones aprendidas de otros proyectos, el conocimiento de la organización en la que se desarrolla el proyecto y de su grado de aversión al riesgo…
¿Qué otros factores humanos consideras que pueden afectar a la gestión de riesgos de un proyecto? ¿utilizáis aplicaciones en vuestras organizaciones que os ayuden en este proceso?
—— ENGLISH VERSION —————
Some days ago I attended a presentation of a risk management tool, applicable to project management but also to other environments.
The tool performs a big number (configurable) of simulations based on the estimations made by the project manager and its team, according to the Montecarlo method.
What is Montecarlo simulation?
Montecarlo simulation consists on the creation of a mathematical model of the system to be analyzed and the identification of the inputs or variables whose random behavior determines the behavior of the whole system.
After that, random samples (specific values) are generated using an application. Those samples are used as inputs of the system and the outputs are used to analyze its global behavior.
Repeating n times this same process it is posible to obtain n results that allow to understand better the way it works. The bigger the number of samples the more precision in the analysis.
In our environment, the input variables would be, for instance, the variances in cost or in the duration of project activities depending on some risks that might finally materialize or not. As a result, the application provides some graphics with the probabilities to finish a project in a specific date or with a specific cost.
Nowadays technology can help us a lot, specially in projects of high cost and / or in those projects where not finishing on time may risk infrastructures or even human lifes. In these situations these kind of tools can be very helpful.
The human factor
But the reason that has motivated me to write this post is the thinking that all the information needed by the tool must be previously provided by humans; the probability and the estimation of the impact in the case that an specific risk may finally happen, the exhaustive identification of the risks that may affect to a project, the criteria to define the probabilities and impacts matrix … If there are important mistakes or gaps in this data the later calculations made by the machines will be wrong.
The experience of the project manager and its team, their training, the chance to have a multidisciplinary project team, capable to have in mind all the potential risks and the ways they would affect the whole project, the possibility to have a good base of lessons learned available for the whole organization, the knowledge of the organization that is developing the project and its risk aversion, …
What other factors do you think that may affect a proper risk management in a project? Do you use applications in your organizations that support you in this process?
¿Qué hacer si durante la fase de ejecución y seguimiento/control nos encontramos con que no hemos identificado a un interesado (stakeholder) en nuestro proyecto que, además, resulta que tiene mucho interés y/o influencia en el mismo?
La gestión de interesados es un proceso vivo durante todo el proyecto
La gestión de los interesados es, en cierto modo, como la gestión de los riesgos en nuestro proyecto; no debemos darla nunca por cerrada y hay que revisarla sistemáticamente. Periódicamente es necesario revisar el registro de interesados, el análisis de cada interesado y la estrategia utilizada con él, para introducir los cambios que sean necesarios.
Inclusión de nuevos interesados durante el proyecto
El inicio del proyecto es la fase en que menos información disponemos. Si, como planteaba la pregunta inicial, nos hemos olvidado o no conocíamos a alguien importante deberemos:
1. Añadirlo al registro de interesados.
2. Evaluar su poder dentro de la organización y su posible interés en relación al proyecto.
3. Analizar cómo puede haber afectado al proyecto su no inclusión hasta la fecha en el grupo de interesados.
4. Definir una estrategia para gestionar nuestra relación con él, partiendo del reconocimiento de que no hemos empezado con buen pie.
5. Efectuar las correcciones necesarias en nuestro Plan de Proyecto, de acuerdo con el sistema de gestión de cambios que hayamos definido, para tener en cuenta a este nuevo interesado. Ésto es especialmente importante si su nivel de influencia en el proyecto es alto.
Técnicas de identificación de interesados
Para evitar que un interesado, especialmente uno importante, se quede fuera de nuestra estrategia de comunicación del proyecto hay algunas herramientas que podemos usar:
– Nominación de interesados: a partir de una lista inicial podemos pedir a cada uno de los interesados ya identificados que nos proponga nuevos interesados en el proyecto. Es recomendable empezar por el sponsor del proyecto y continuar luego con los interesados más influyentes.
– Investigación de base: se trata de estudiar toda la documentación existente en relación a nuestro proyecto y localizar en la organización documentación análoga de proyectos similares. A partir de aquí se toma nota de todos los interesados que aparezcan en dicha documentación, para evaluar si también pueden estar involucrados en nuestro proyecto.
Esta técnica es especialmente interesante si somos directores de proyecto trabajando en una organización nueva para nosotros o que desconocemos.
– Rueda de interesados: La rueda interesados es una especie de lista de control en la que se han identificado todos los principales grupos de interesados. Se usa para comprobar la lista de grupos de interés frente a grupos de interés genéricos, con objeto de identificar los que falten.
Es bueno actualizar la documentación del proyecto (lecciones aprendidas) con nuevos grupos o roles que se hayan identificado, para que pueda ser aprovechada en futuros proyectos.
Resumen final
La no inclusión de un interesado importante dentro del Plan de Proyecto puede ser catastrófica. Para evitarlo, utiliza las tres técnicas mencionadas de identificación de interesados y revisa sistemáticamente tu registro de interesados del proyecto y tu estrategia frente a cada uno de ellos.
¿Qué otras técnicas conoces para identificar interesados? Compártelas mediante un comentario a esta entrada para que todos nos beneficiemos de su uso.
Vivimos tiempos de profundos cambios. Posiblemente por el hecho de estar en pleno ojo del huracán no seamos conscientes de lo mucho que está cambiando nuestra vida en los últimos años. Y lo que queda.
Los cambios generan incertidumbre y la incertidumbre da paso al estrés. ¿Estamos preparados para gestionarlo? La situación es complicada porque es importante tener autocontrol y gestionar correctamente nuestras emociones en casa con la familia, en la oficina con nuestros compañeros de trabajo, jefes o clientes. Y lo cierto es que las tensiones se observan a cada paso que das.
He leído bastante sobre el tema y he practicado algunas técnicas. No me considero un experto ni mucho menos pero sí que me gustaría compartir (siguiendo la filosofía básica de este blog) algunas ideas con vosotros, por si os pueden ser de utilidad.
Hay técnicas aplicables a la gestión de proyectos y técnicas aplicables a nuestra forma de actuar personal, como jefes de proyecto.
En mi opinión un concepto fundamental es asumir que no tenemos el control. Con frecuencia pensamos ésto pero nuestra mente se empeña en mantenernos en una especie de falsa ilusión de que tenemos el control de nuestra vida, de nuestros proyectos. Sin embargo, momentos clave como la muerte repentina de un ser querido o las drásticas decisiones empresariales que están a la orden del día y que cambian de un plumazo la vida de muchos trabajadores o el rumbo de muchos proyectos nos vuelven a poner en nuestro sitio y nos sirven para recordar que somos muy pequeños y que sería muy osado creer que lo controlamos todo.
Es inútil preocuparse, y mucho menos enfadarse, por aquellas cosas que no podemos controlar. Debemos centrarnos en hacer bien todo aquello que depende de nosotros y olvidarnos de todo lo demás. En el ámbito de la gestión de proyectos, a mi me ayuda mucho una buena gestión de los riesgos del proyecto: no podemos evitar que algunas cosas pasen pero sí que podemos preverlas, analizar cual debe ser nuestra respuesta (si es que debe haber respuesta) y prepararnos para poder actuar cuando sea preciso.
No todo es previsible y solucionable pero saber que has previsto respuestas frente a los principales riesgos de tu proyecto te da tranquilidad. Una vez hecho ésto, relájate y disfruta. Y periódicamente, dentro de la vida de tu proyecto, vuelve a revisar riesgos. Algunos de los anteriormente identificados se podrán descartar ya y probablemente aparecerán otros nuevos que habrá que gestionar.
No tenemos el control de nuestra vida
A nivel más personal, lo que nos hace daño no es lo que nos sucede sino la forma como reaccionamos ante lo que nos sucede.
Otro concepto importante. Debemos vivir el ahora, no el pasado (que ya no está) ni el futuro (que puede no ser como esperamos). No debemos pasarnos la vida, perdiendo el tiempo con nuestra mente siempre viviendo en un momento que no es el presente, el único que es real. Hay que tratar de olvidarse del futuro y de las consecuencias de nuestros actos del presente. La mente debe estar centrada en el ahora y lo que deba venir ya vendrá. Sobretodo, y vlviendo sobre un concepto anterior, si no depende de mi lo que suceda en el futuro no vale la pena preocuparse por ello. En inglés, esta actitud se describe como “mindfulness“, que en español podríamos traducir como “conciencia plena”. No quiero extenderme en ello porque hay muchos recursos sobre el tema en internet y es algo que va más allá del propósito de este blog.
Conclusiones
No te obsesiones por tener el control. No es posible.
Ten una actitud flexible, previendo posibles eventualidades y preparándote para ellas. Una vez hecho ésto, olvídate de los riesgos que corres hasta que un desencadenante haga que se materialicen y, con ellos, tu respuesta. Mientras ésto no se produzca, estate tranquilo y céntrate en el ahora, no en el futuro ni en el pasado. Haz bien tu trabajo.
Periódicamente revisa de nuevo los riesgos de tu proyecto, para adaptarte a los cambios.
¿Qué opinas de estos planteamientos? ¿crees que te pueden servir? ¿qué técnicas utilizas para gestionar la incertidumbre en tu vida personal o en tus proyectos?
La sesión resultó muy interesante. Conocimos los fundamentos de la metodología PRISM y también sus objetivos, de entre los cuales destacaría el compromiso de hacer que las actividades asociadas a los proyectos que llevamos a cabo dentro de nuestras organizaciones sean sostenibles y se limite y controle el impacto que tienen en el entorno en el que se realizan. Todo muy en línea con conceptos como responsabilidad social corporativa y sostenibilidad.
Algunos de los momentos más interesantes de la sesión se dieron al final, en la tanda de preguntas.
Muchos de los compañeros del capítulo expresaron algunas dudas sobre la viabilidad de esta certificación en el contexto económico en el que nos encontramos. Seamos realistas, el criterio número uno (y con diferencia) que siguen las empresas a día de hoy en la gestión de sus proyectos es la rentabilidad y el control de los costes. La ponente, Lorena Perdomo, de avanzaproyectos, se esforzó en convencernos de que el reto está en conseguir ser sostenibles sin incrementar por ello los costes de los proyectos; ahí es nada.
Sin embargo, mi opinión es que si en el futuro un país quiere mantener ciertos niveles de bienestar debe aspirar a gestionar sus empresas y proyectos teniendo muy presentes los criterios económicos pero midiendo también muy bien su impacto en el entorno; la afectación medioambiental y social.
Desconozco, y no me atrevo a aventurar, qué recorrido tendrá esta certificación entre los profesionales de la gestión de proyectos pero, de entrada, es de agradecer que ponga sobre la mesa nuestra responsabilidad sobre la afectación que nuestros proyectos tienen en el entorno tanto durante como después de su ejecución.
¿Qué opinión tenéis sobre el tema? ¿qué pensáis de esta nueva certificación? ¿os planteáis habitualmente cómo afectan vuestros proyectos al entorno en el que se desarrollan o os limitáis a ejecutarlos? ¿qué grado de influencia pueden tener los project managers sobre las empresas en que trabajan para que se tengan más en cuenta los criterios de sostenibilidad en la gestión de proyectos?
Technology at the service of humans 