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 ...

In the beginning was waterfall, and it was flawed. Then along came iterative approaches, and whilst these delivered many examples of satisfied customers and project success, could the breadth of benefits initially claimed by Agile evangelists have been a case of slight overreach? Was Agile failing to address a growing perception its interface centric approach and focus on rapid delivery chose fancy yet flaky over scalable and resilient? Naturally, product managers were attracted to the speed with which they could excite customers with proofs of concept (PoC) that too often did not get re-factored for production deployment. The days of vaporware were gone as a working demo could be completed in the same time as a marketing PowerPoint. But is what is good for some customers good for the consumer? Many Agile practitioners I know lamented the pressure they were under to productise or deploy the PoC once the product owner had prematurely showcased it to executives or customers and over pr...

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,...

According to the tables at the top of the early Standish Chaos Report into why projects fail are the quality of business requirements followed by the lack of involvement or engagement of users. This reading was often used to extrapolate project failure largely to the BA, with user engagement being cited as the Business Analysts responsibility. On the flip side, I cannot recall BA's receiving significant attribution for project success when they succeed having quality requirements and strong user relationships. So who was making the call that requirements inadequacies ruined the project or is it just a case of who is being asked to explain why and what interests they have in who they blame? Reading just a little further down this same report, managers with projects failing all around them do not mention requirements at all. They see a broader malaise that results in it being nearly impossible for the BA to be successful which is attributes of management including; poor attitudes...

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...