#PMChat

The Open Source Project Management Community

¿Como usar Valor Ganado para decidir "matar" un proyecto?

Acabo de encontrar un sitio interesante. Es el sitio de TheBigRedTomatoCompany , en Inglaterra. En su sección de Administración de Proyectos, podemos leer el siguiente artículo: “Cuando se debe matar un proyecto”, propuesto por Matthew Needham.  Mattew inicia preguntando: Cuando se ejecuta un proyecto y este se empieza a atrasar, ¿Cómo decidimos si debemos continuar o se debe detener el proyecto en forma anticipada?  Y para responder esta pregunta, Mattew sugiere usar el análisis del valor ganado.  La propuesta es simple: La inversión en el proyecto debe estar alineada con el valor obtenido por la ejecución del mismo.  Si el importe del gasto es superior al valor creado en cada uno de los hitos, entonces es probable que el proyecto termine retrasado y costando más que lo programado.  Un segundo artículo, titulado ” Uso de Gestión del Valor Ganado como una señal de alerta temprana en Gestión de Proyectos ” nos recuerda que a ntes de que se inicie el proyecto, el equipo de trabajo debe sentarse y preparar un plan. Este plan determinará los objetivos del proyecto. Luego, mientras el trabajo avanza se deberán realizar exámenes de los avances del proyecto, y d ando seguimiento en forma cotidiana al costo del proyecto y comparándolo con el valor entregado, la gerencia puede realizar el seguimiento del valor ganado del mismo y tomar acciones respecto al exceso de gastos antes de que sean un gran problema.  En algunos casos puede ser evidente que completar el proyecto costará mucho más de lo previsto originalmente y tomar mucho más tiempo que el programado en un inicio. Y esto significa que, aunque el proyecto ya esté comprometido, la gerencia podría tomar medidas para “matarlo” antes de que cueste más dinero.  Mattew propone un ejemplo.

More:
¿Como usar Valor Ganado para decidir "matar" un proyecto?

Book Review: No Wishing Required

Written by Rob Prinzo No Wishing Required: The Business Case for Project Assurance is a semi-fictional work underpinned by a problem that affects many IT related projects – a lack of solid yet pragmatic project assurance.  Prinzo’s background is complex software implementation projects for large Corporates and Government Agencies. The lessons he’s learned and experiences he’s had throughout his career are well observed and addressed by the books central characters, Jenny and her manager and mentor Bill Parker. The book flows well as Prinzo mixes both fiction and non-fiction to great effect. He takes the reader through the reality of managing and implementing enterprise applications technology supporting that throughout by using Bill and Jenny’s on-the-job reality. In order to introduce and explain his collaborative intervention SM approach, Prinzo uses Bill, who’s been there done that and got the t-shirt, to help Jenny understand the Intervention Process Pyramid and the Attributes and Behaviours of the Interventionist ultimately leading her to comprehend the differences between project managers and leaders. Key Messages: ‘Managing projects to success by addressing failure before it occurs’ writes Prinzo, is the fundamental purpose of project assurance and the underlying principle of collaborative intervention SM . Companies, Managers, Leaders, Project Managers, and anyone in an operational or project role who’s ever been involved in type of IT related project will recognise these key messages covered by the book.

Read the original post:
Book Review: No Wishing Required

4 Tips from a Sling Shot

We know change projects can be difficult beasts. Yet we often ignore how we, the people involved in delivering or receiving the change, multiply those difficulties through our own learned behaviours. We’ve let what we’ve been told or read in the multitude of business books, blogs and training programmes automate us and what we do. Don’t get me wrong, process has its place. Checks and balances are necessary and process provides them but when the spotlight focuses on following the process rather than on the results it’s there to enable, the reasons behind implementing a process have been lost. So if we simplify the process we’ll get better results, right? That will definitely help

View the original here:
4 Tips from a Sling Shot

Delegate Effectively and Thoughtfully

In order to become a highly effective and truly successful project management leader you must focus on the areas that make the most difference to the success of your project. These areas include risk and issue management, project planning, managing senior stakeholders, ensuring quality of the end product, and leading and motivating the team. Delegating lower level administrative tasks and detailed planning is important if you want to spend your time effectively.    By delegating, not only do you free yourself up to focus on what is really important, you also help grow and develop other people. When you delegate correctly, you motivate and stretch the person you are delegating to, and you contribute to his or her professional development needs, confidence, and competence.  Many project managers don’t delegate because they believe that they either have no one to delegate to or they don’t want to lose control of a certain task. You need to think more broadly, creatively, and strategically. Often team members are perfectly able to perform a task—for instance, one related to detailed planning and estimation—if they are given the opportunity and the right amount of support.    To delegate effectively, be conscious about what you delegate, who you delegate to, and how you delegate. Keep the following in mind:    Use Pareto’s Principle – Never delegate the 20 percent of tasks that contribute to 80 percent of your results.

View article:
Delegate Effectively and Thoughtfully

Reflexiones sobre la versión preliminar de la quinta edición de la Guía para Administración de Proyectos

Ante la inminente aparición de la 5ª Edición del PMBOK (C) , algunas personas que ya han tenido oportunidad de revisar el documento preliminar comienzan a compartir sus comentarios.  Tal es el caso de Andy Crowe , que el blog de Velocitech  nos presenta sus reflexiones al respecto.  Dice Andy que los grupos de procesos tradicionales de inicio, planificación, ejecución, seguimiento y control, y el cierre no se han modificado. Este sigue siendo el marco para el flujo de los procesos y actividades.  Las áreas de conocimiento se han ampliado para incluir la gestión de interesados, y Andy destaca que si bien la gestión de interesados era parte de la gestión de la comunicación, todos sabemos que la gestión de grupos de interés real puede requerir más que comunicación.  Cuando se publique la 5ª edición, contemplará 47 procesos según el documento preliminar. Esto representa un aumento del 12% con respecto a la 4ª edición y hay alguna reorganización para dar coherencia. Andy presenta un par de gráficos en su artículo, que no voy a reproducir aquí pero que invito a leer.  Lo importante del artículo es el análisis que sigue:  Esta propuesta alcanza un nuevo récord, con 614 entradas, herramientas y salidas, que representa un aumento impresionante de 19% respecto a la 4ª edición. Otra curiosidad es que sólo se ha encontrado la palabra “ágil” un total de seis veces en el cuerpo del documento y no aparece glosario.  Andy se pregunta por qué ocurre esto, considerando la relevancia que los métodos ágiles han tomado en los últimos tiempos (incluso al interior del PMI).  Y esto plantea una pregunta interesante: ¿el PMBOK pretende ser una guía a toda la gestión de proyectos o solo de los proyectos en los que aplique el método de la cascada?  Si se pretenden abarcar los conceptos ágiles, entonces es curioso que las palabras “planning poker”, “Fibonacci”, “auto-organización”, “osmótica”, y “desagregación” no aparezcan en ninguna parte en la versión preliminar del documento, mientras que técnicas tradicionales como “Delphi”, y “WBS” están bien representadas.  Andy se pregunta si habrá la necesidad de un cuerpo de conocimiento independiente para métodos ágiles.  Cierra su evaluación con un juicio: el PMBok sigue aumentando de tamaño, y en la misma proporción aumenta la complejidad de su uso. Las organizaciones tratan de desarrollar metodologías de esto, y cada cuatro años, estas sufren cambios importantes.

Taken from:
Reflexiones sobre la versión preliminar de la quinta edición de la Guía para Administración de Proyectos