theagileprince.com

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