The failure rate of IT projects is a concern for any new project.\u00a0 Unfortunately, this is a valid concern when you consider the failure rate is around 25% across all projects.\u00a0 Small projects are more likely to succeed.\u00a0 However, one in five is still likely to end in failure.<\/p>\n
The cost of failure can be substantial.\u00a0 Although the dollar amount for small projects may be less, the impact to the business can still be crippling.\u00a0 It is not uncommon for core business functions to rely on the success of these projects.<\/p>\n
Systems have gotten much more complicated and will continue to do so.\u00a0 We have more users, more devices, more data, and more systems to integrate each year.\u00a0 That adds up to more potential points of failure.\u00a0 Thus, it is not likely that the failure numbers will get better.\u00a0 On the other hand, a look into the reasons why projects fail reveals easy fixes.\u00a0 When you distil the most common problems to their essence, the failure details\u00a0are mistakes that would doom any endeavor.<\/p>\n
<\/p>\n
Every article and book I have read about project failure include reasons that center around poor requirements.\u00a0 Correspondingly, my experience has included a lot of examples to support these claims.\u00a0 Of course, this makes all the sense in the world.\u00a0 Assume you ask someone to build a house and fail to specify the number of bedrooms, baths, and floors.\u00a0 What is the likelihood the home builder will be successful?\u00a0 IT projects are far more complex and thus require much more definition.<\/p>\n
All too often projects jump into implementation on the strength of sketches on a napkin.\u00a0 Someone puts together a few PowerPoint slides, tosses in some descriptions and arrows and coding begins.\u00a0 It only makes sense that this approach leads to failure.\u00a0 We need to step back and consider whether our vision is\u00a0fully captured.\u00a0 I know there is an urgency to turn our ideas into reality, but jumping into implementation is not the answer.<\/p>\n
<\/p>\n
Similar to the lack of definition is a lack of communication.\u00a0 This can start with the project vision not being properly communicated, but that is only the tip of the iceberg.\u00a0 The goals of a project need to be communicated to everyone involved.\u00a0 I don’t mean specific goals to everyone, but overall goals need to be shared and expectations set. \u00a0An excellent communication approach for this is through a timeline and milestones.<\/p>\n
When a team is on the same page for tasks and timing, it goes a long way in promoting success.\u00a0 This includes staying informed about status and progress.\u00a0 Projects will run into bumps and unforeseen problems.\u00a0 When these are communicated correctly, then the team can adjust to them.\u00a0 When they are not properly shared small slips can become significant and, expectations may not be met.\u00a0 You don’t drive down the highway with your steering wheel locked in place.\u00a0 Likewise, you can not use that approach in project management.<\/p>\n
The third bucket of project failure reasons is one we call usability.\u00a0 This is a rather large umbrella that includes business application and general usefulness.\u00a0 I have seen a lot of projects fail for these reasons.\u00a0 The typical problem is that there is a disconnect between the key stakeholders and those in the trenches that will use it.\u00a0 Usually this disconnect centers around business rules and how they are implemented.\u00a0 I see the latter problem arise in new ventures and directions where the goals have not been fully worked out.<\/p>\n
In smaller projects, this failure reason often comes about because the project owner fails to understand the impact of their decisions.\u00a0 This is often due to lack of a firm understanding of their business and regulations.\u00a0 It also comes from shifting business requirements.<\/p>\n
I can not begin to count the number of times I have seen projects start with a general concept (e.g. we want to be the Uber of green salads) and there is a solution created for it.\u00a0 Unfortunately, as the project progresses, the goals change.\u00a0 The change comes from deeper insight into the business idea. \u00a0This leads to adjustments to be marketable or profitable.<\/p>\n
In large projects, this often comes from stakeholders and project owners being too distant from the end users. \u00a0The big picture business may be understood. \u00a0However, there is a lack of understanding of how the day to day work is accomplished.\u00a0 This leads to gaps in data collection, unneeded data being collected, and other problems.\u00a0 Unfortunately, these fail to manifest until the end users start working with the application.<\/p>\n
<\/p>\n
There are volumes of books written on design and planning.\u00a0 This is because proper planning and design are crucial factors in the success of a project.\u00a0 When a project is started, make sure that enough time is spent on these areas. \u00a0The likelihood of success will increase dramatically.\u00a0 Factors not mentioned in this article like availability of resources, lack of proper skills, and other implementation risks can be mitigated with proper planning and design.\u00a0 These are not “silver bullet” corrections you can make to your next project, but they are pretty close.<\/p>\n
<\/p>\n
https:\/\/project-management.com\/top-10-reasons-why-projects-fail\/<\/a><\/p>\n http:\/\/www.amanet.org\/training\/articles\/why-projects-fail.aspx<\/a><\/p>\n http:\/\/www.cio.com\/article\/2380469\/careers-staffing\/why-are-so-many-it-projects-failing-.html<\/a><\/p>\n Gartner Survey Shows Why Projects Fail<\/a><\/p><\/blockquote>\n