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

What is scope creep? Scope creep, also known as requirements or feature creep, is the in-flight addition of requirements, expanded goals, rework or changes post build, to previously agreed deliverables. The lack of control and threat is often due to the fact an impact assessment is not done or the impact does not trigger the formal change control process. So if these types of changes are too minor to require management by formal change processes, how is it they may have such an impact on a project outcome? Of course project delivery is about delivering fit-for-purpose outcomes which often requires going above and beyond the call of duty to achieve customer satisfaction. This flexibility is part of the domain we operate in, so it sounds completely logical to accommodate small or apparently zero impact changes as required. Point one is definitely true, but the second is a value based proposition. In slotting in a minor change by working after standard hours as an act of goodwill,