The Scrum Guide says that everyone must understand what “Done” means. It sounds right, but let’s tackle it down.  There is a trend in the Agile software development project management practice community that states that “no requirement or piece of software can be considered DONE  until it is put to use”. This one sounds right at first, until you put to use any piece of crap whose committed changes build successfully on the continuous integration subsystem. G. Alleman points out that any piece of software should be related to a measure of effectiveness about the needed capabilities in the business case.

This point of view should pervade from the measures of effectiveness to the measures of performance of the software installed. The evidence of done  should populate the Work Breakdown Structure with a deliverables based description, or, at least, a deliverable column in the spreadsheet . This description must be clear enough for all actors involved. The technical terms should be widely recognised, or otherwise term clarification should be added.

Once the deliverable is clear, there are some environmental  or culture factors the project team should agree on. How products are tested, which is the required quality, who is accountable, these ones are corporate factors that must be understand by everyone. You could work for a business fond of “The Cult of Done Manifesto“, where laughing at perfection is welcome, or a pharma corporation that double checks everything or performs triple blind tests. But the meaning of done must be crystal clear for everyone. Do you agree? Not agree? Mmmm.

Check list

CC-by-sa Ben Brown

 

Advertisements

Implicaciones en la gestión de riesgos

Agradecimientos

La redacción de esta memoria de investigación ha sido una empresa costosa, debido a las difíciles circunstancias profesionales y personales en las que me he encontrado. No obstante, a través de estas circunstancias y de las incertidumbres propias de la investigación, la tarea de definición y transcripción de los conceptos ha terminado por aportarme una sensación de plenitud que ha compensado todos mis esfuerzos.

En la lista de personas que me han ayudado a llevar a buen puerto esta investigación, tengo que citar en primer lugar a mi director de tesis Joaquín Ordieres Meré. No sólo despertó mi interés por el tema en los cursos de doctorado, me lo planteó como estudio previo en la tesina y formalmente como objeto de investigación para una tesis, sino que ha tenido voluntad y paciencia de dirigirlo hasta el final, sabiendo colaborar, exigir y comprender.

Durante la investigación de este tema he tenido la suerte de trabajar en la Universidad de La Rioja y en la Universidad Pública de Navarra – Nafarroako Unibertsitate Publikoa. En ambas he encontrado el clima adecuado para esta empresa científica. Quiero agradecer a los compañeros de los Servicios Informáticos de ambas universidades la ayuda que me han prestado siempre amablemente. Me gustaría recordar especialmente al personal de la biblioteca de la Universidad Pública de Navarra y a su Director Guillermo Sánchez Martínez, cuya colaboración y eficacia han sido excelentes. A Cristina Juanmartiñena Fernández, por su ayuda con las traducciones de varios idiomas europeos. A Victoria Rodriguez Zarza, por la paciente y exhaustiva corrección de las sucesivas versiones de esta obra.

Quisiera dedicar este trabajo a las personas que me han ayudado a llevarlo a cabo. A mi esposa Jazmina, e hijos Leire y Aritz Eztebe, por el tiempo que les he robado para la ciencia. Y sobre todo, a mis padres, que tanto han esperado de mí.

Resumen

En este trabajo planteamos un modelo del riesgo en el proyecto en red estocástico, expresado mediante redes de Petri estocásticas más generales. El modelo contempla la incertidumbre sobre la duración de las actividades, e incluye los planes de contingencia y los ciclos de repetición. Caracterizamos probabilísticamente la incertidumbre sobre el resultado exitoso o fallido del proyecto como conjunto y de cada una de sus actividades.

En el modelo se incluyen distribuciones de probabilidad para las variables aleatorias ligadas a la duración de las actividades. A partir de una simulación de Monte Carlo, se ejecutan algoritmos de secuenciación y asignación de múltiples recursos cuyos resultados agregados muestran una información completa sobre las expectativas de comportamiento de la red estocástica del proyecto.

Hemos desarrollado un prototipo de software en Java para demostrar la aplicabilidad de nuestra propuesta. El prototipo toma como entrada un proyecto o un portafolio de proyectos, y ejecuta los algoritmos de planificación para ofrecer la información sobre criticidad, probabilidad de éxito, consumo de recursos, coste, duración, etc…

El modelo de riesgo y el prototipo se han probado en un conjunto de proyectos de pequeño tamaño encontrados en la literatura y en la práctica profesional. Los experimentos han demostrado que la información obtenible para la gestión del riesgo en el proyecto es más extensa y precisa de la que se obtiene con las técnicas en uso.

Este modelo de riesgo puede ser adecuado para nuevas áreas gestionadas por proyectos donde el riesgo es significativo, como la investigación, las tecnologías de la información o el desarrollo de nuevos productos.

Seguir leyendo la tesis Sistema de planificación estocástico de proyectos: Implicaciones en la gestión de riesgos

One of the most important aspects of project portfolio management is the alignment with the corporate strategy. You are supposed to draw any form of criteria from this strategy, and then prioritize all projects against them. You can found some clever tips on the issue in the work management blog.

World War I -- SATC (Students' Army Training Corps) pole-climbing training for telephone linemen, 1918.

These are good pieces of advice, in case you have got a clear strategy handy. But how do you align projects when you have got some faint brushstrokes of the strategy? When your company has written down a painfully obvious mission statement, a lousy strategic plan, an unrelated investment plan with a 13 year span that dwarves Joseph Stalin‘s wishful planning capacity, and a third unrelated strategic plan for economic development? This is an alignment nightmare, but it could be worse. This strategic patchwork could be completed, at different paces, with new departamental strategic plans, some so-called road-maps to new objectives, and some horizontal programmes enthusiatically pursued by underfunded tiny offices.

Then you can throw the portfolio and program management theory away and prepare to select projects by pure instinct, and to priorize them by negotiation.

Have you found similar problems when aligning projects and strategies in your organization?

Iñaki Agirre