5 Rebuttals to InfoWeek’s “5 Reasons Tech Projects Fail” Article

Posted by UltraShipTMS on Apr 29, 2013 in Blog | 0 comments

5 Rebuttals to InfoWeek’s “5 Reasons Tech Projects Fail” Article

InformationWeek’s  “Intractable IT Guy” aka Coverlet Meshing (an amusing pseudonym) has an interesting article in the April 22 issue entitled, “Why Tech Projects Fail: 5 Unspoken Reasons”.  Here’s a link.  Go ahead and read it, then come back and read the rest of this post; I’ll wait…

Back?  Good!  If you didn’t take the time to read it, I will break it down for you and then explain how for our part, UltraShipTMS is built to avoid these obviously commonplace obstacles to satisfaction with enterprise software.  According to Meshing,

1)      Technology ROI numbers are mostly fiction

2)      ROI rarely drives the tech investment decision

3)      There’s rarely any long-term accountability in technology

4)      Detailed plans are the enemy

5)      Bringing in the big outside guns ensures someone gets shot

While most of what Meshing discusses relating to these 5 reasons is likely true when it comes to macro solutions – ERP s produced by the IBMs, Oracles or multi-tenant TMSs produced by the likes of JDA and LeanLogistics – more nimble providers of innovative technology don’t necessarily fall into the traps he mentions.

Regarding Reason 1:  Yes, many organizations ignore the most complex ROI variable – “the cost of the business re-architecture required to consume a proposed technology.”  When a customer is informed of harsh realities and resolved to making the difficult choices required, then there’s rarely disappointment with ROI. A good technology partner knowingly risks losing a sale by illuminating the changes required if the implementation is to be successful.

Reason 2 examines conflicts of interest between the advancement of the honchos who would greenlight a solution and the overall good of the organization.  A solid partner succeeds by demonstrating value to all would-be users and doesn’t just focus on winning support of the HIPPO or C-suite.  When the value proposition is internalized by users at every level, the software sells itself and the results soon follow.

Reason 3 blames frequent job switching among IT pros for hampering accountability in projects typically spanning 2 to 5 years. This is only problematic when companies select solutions that lean too heavily on internal IT resources to manage and maintain.  The best partners deliver ample support and training freeing IT for more strategic pursuits.  When the original champion moves on to higher station, the partner remains to bridge the gaps, provide continuity to the new boss and maintain pride of ownership in the solution amongst IT workers.

The analysis paralysis or “death by details” discussed in Reason 4 draws the wrong conclusions from typical obstacles.  Yes, the outside world is changing rapidly and scope creep is inevitable.  Yes, organizations invest significant time and energy in detailed planning as a hedge against the unknown.  But when circumstances demand change, it is not the fault of prudent planning if the improperly chosen solution cannot flex or quickly adapt.

By the time an organization gets to the breaking point described in Reason 5, they’ve already screwed the pooch.  A sober assessment of what should be within and outside of the internal IT teams’ core responsibilities should happen at the point that technology is first considered as a solution to a business challenge.  The question to ask then shouldn’t be; “Can we do this with our available IT resources?”  Better to ask, “Who can do this best, our internal resources or a well-researched provider/partner?”  Bringing in an outside gun to troubleshoot the failed implementation left behind by the last poorly-chosen outsider is a morale killer and brain drain.  But if the decision-making and selection process were completed with the proper eye towards sustainability and long-term partnership, no one needs to be shot.

Leave a Reply

Your email address will not be published. Required fields are marked *


*