theagileprince.com

Is PRINCE2 and iterative development (such as big 'A' Agile) friend or foe?   As a rule, opinions are generally polarised between those who have been sold Agile as the panacea that will inoculate projects from failure or those dismissing it as a dogmatic fad that is a recipe for chaos, cost overrun, flaky products and subsequent failure. You may have a positive view of Agile benefits but this agility, without more robust governance, may be a bridge too far for decision-makers accountable for funding. When evaluating a project approach, consider the benefits of the middle path - nobody need be right or wrong, why can't we all just get along! To start, think about the responsive and continuous improvement benefits of Agile coupled with the governance, greater predictability of scope, schedule and cost and risk management that are part of full scale project management? What gaps would exist in the rigour of your approach, and what problems exist with picking a

Introducing Agile into a waterfall environment can be a challenge not only because of the problems associated with learning, deploying and applying new techniques, but also because business stakeholders may have interests or bias over the way projects are delivered. The decision to try Agile often results from the organic growth of PM's or other delivery resources with Agile experience within the ICT department. These people either agitate for change or introduce some of the tools and techniques that are hallmarks of iterative delivery (story boards, product backlogs. stand-ups and retrospectives) that subsequently highlight benefits the approach delivers. Another common way is the PMO or ICT Manager believe a particular type of project is specifically suited to Agile delivery. The most important objective of any project should then be to get going early and as cheaply as initiation and planning governance in the domain allows. As the initiative proceeds, gain experience, l

Cobb’s Paradox: “We know why projects fail; we know how to prevent their failure – so why do they still fail?”. It may sound overly simple to say it, but the answer is right there in part B of the question, "we know how to prevent their failure" . Quite simply, this equates to those who are accountable for the things we see will cause the project to fail, where the are solvable, are not making those responsible take the required action. So why do projects fail; there are simply too many reasons, but the key one is if we know how to prevent it - why is this not acted upon? A project only truly fails if it doesn't achieve the intended benefits. If you are late, over budget, or scope / quality not as planned, but despite this the benefits are realised, then the project has succeeded though you as PM have failed in project delivery (covered a bit more here - How important is project success to you?) . To frame the discussion; 1. what is project delivery failure, s