theagileprince.com

Are you willing to say anything other than an obvious “it is everything and I’ll do whatever it takes to achieve it”. Admirable, but what does ‘whatever’ mean? Would you throw in some of your own money to get additional resources to meet an immovable deadline? You may be prepared to work 24×7, but unless the team who actually do the work can, will that help? Martyring yourself may be an instinctive rearguard action, but it will do little for your stakeholders. Have you thought that meeting timelines, budget and quality constraints may give you only part or none of the success? Meeting these constraints means successful delivery of what was planned, and the vehicle used to achieve this may function correctly - is that your job done? All your good intention is moot if your finely tuned vehicle arrives at the wrong destination. A hint from Peter Drucker; " There is nothing quite so useless as doing with great efficiency what shouldn't have been done at all! ".  Deli

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