Government // Enterprise Architecture
Commentary
4/4/2013
02:43 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%
Repost This

Why Tech Projects Fail: 5 Unspoken Reasons

Today's IT groups make too many ROI guesstimates and have too little accountability, says this financial industry IT exec, in his debut column for InformationWeek.

The usual response to this short-term culture, a three- to five-year vesting period for bonuses, doesn't actually encourage long-term thinking. Not when internal mobility is involved and definitely not when there's market- and industry-level competition for talent.

It should never come as a surprise when "too big to fail" stumbles, and spectacularly. What should be a surprise is when project planning contributes to that failure. What's missing in the business and/or IT project plan is agility, the organizational ability to act quickly and decisively. Because the opposite of big isn't small; it's nimble. It's culturally porous, focused on transparency. It's responsive and adaptive.

Helmuth von Moltke got it only half right when he said: "No plan survives first contact with the enemy." He should have said…

4. Detailed plans are the enemy. They're rigid, set too far in advance and take up so much management time that long-term planning is itself a risk to be mitigated. Project plans that extend past 90 days are as accurate as TV weather predictions.

The challenge if you're big is that it takes you longer than 90 days to get out of the bathroom every morning, which means that your business conditions -- the most important context for your IT projects -- change faster than the project. It's why users often reject technology that gives them what they asked for: By the time the technology is delivered, it's no longer what they need.

When the world outside is changing rapidly, IT projects should be forced into redefining themselves -- and often. Scope creep should be mandatory. Without it, IT's relevancy comes into question. With it comes the adoption of any new deliverable.

The institutional response to the need for speed is to bring in outside accelerators -- the IBMs if your company can afford them or the TCSs if they can't. The surprising part of that decision is that…

5. Bringing in the big outside guns only ensures that someone will get shot. It's the corporate equivalent of keeping a loaded .22 on your nightstand. There are two truths in that analogy. The first is that the only solid advantage outsourcers provide is that they're easy targets. The second is that .22s do more wounding than killing. They just make a mess that you have to clean up yourself.

The legitimacy that the big-name onshore outsourcers add to a project has less to do with increasing time-to-market and mitigating execution risk and more to do with the arcane calculus of career risk mitigation (see Reasons 2 and 3).

The cost savings that the offshore outsourcers promise are rarely realized and come at the price of increased project complexity. It's already difficult to speak in terms of cultural transformation. Now imagine having to merge and change four massive cultures: your corporate culture, their corporate culture, your national culture and their national culture.

Finally, bringing in outsiders keeps your workforce dumb. It locks you into a vendor interested in getting you hooked on its proprietary black box, the corporate equivalent of a gateway drug.

Outsourcing does transform IT: Engineering as a core competency gets replaced by the cult of sigma; technical leadership gets replaced by scientistic project management. Eventually, the organization has no internal decision-makers with any depth of technical experience. They have no choice but to snort the IBM salesman's lines.

And when the business eventually loses its competitive advantage and starts to become obsolete, it has no choice but to focus on cost reduction; no choice but to light the TCS pipe.

Next up: How do we get to that shining goal on the horizon?

Attend Interop Las Vegas May 6-10 and learn the emerging trends in information risk management and security. Use Priority Code MPIWK by March 22 to save an additional $200 off the early bird discount on All Access and Conference Passes. Join us in Las Vegas for access to 125+ workshops and conference classes, 300+ exhibiting companies, and the latest technology. Register today!

Previous
2 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 3   >   >>
Uladzislau Shauchenka
50%
50%
Uladzislau Shauchenka,
User Rank: Apprentice
8/19/2013 | 12:29:00 AM
re: Why Tech Projects Fail: 5 Unspoken Reasons
Can I recommend a resource?
Why Projects Fail is a 113 pages book featuring project management case studies, analyze of failed projects, suggestions and recommendations.
mracz303
50%
50%
mracz303,
User Rank: Apprentice
8/14/2013 | 7:57:33 PM
re: Why Tech Projects Fail: 5 Unspoken Reasons
Most projects fail due to the lack of the fundamentals. I am old school, I like to understand if the data that i am working with and making my decisions on is valid and accurate. In any busniess case or project start up, question the data presented to you and ask, when was the data updated, by who, what procedures did they use to validate the accuracy of the data and how.
When is the last time you heard inventory, validation, accuracy or the integrety of the data being questioned? I assume not very often. The a high failure rate is due mostly to all of the above point of pain plus poor judgement in regards to the dat used to support the project.
I do understand application projects are of a different bread then IT hardware, but surely if you are basing your project milestones on bad data, you will fail more often then not, on any project.
khizar_07
50%
50%
khizar_07,
User Rank: Apprentice
7/12/2013 | 10:19:14 AM
re: Why Tech Projects Fail: 5 Unspoken Reasons
The reason the projects fail is the the IT outsources overstate their technical know how and the performance of the hardware they are trying to sell. In the end the project does not scale well to beyond a few hundred thousand users and furthermore functionality that was promised is missing because incompetent programmers do not know how to think outside the box.
The whole industry is in disarray with many recent projects only being awarded on a pay for performance basis. If it works they get paid if not then its a loss for the IT outsourcing companies.
If you want a record store that can store and retrieve a few details and does not need to scale past a few hundred thousand users then the IT outsourcers are capable of delivering that.
If you need to have a system capable of supporting millions of users whilst also doing complex logic/calculations and routing messages to different users and computer systems then you have to look elsewhere.
You know the IT Outsoucers are incompetent when they throw around buzzwords such as Big Data! If they knew anything about IT they would understand that technology for search engines is inappropriate for structured databases. Altering a customer record to store an additional filed becomes extremely difficult.
Mark Simchock
50%
50%
Mark Simchock,
User Rank: Apprentice
5/10/2013 | 11:23:03 AM
re: Why Tech Projects Fail: 5 Unspoken Reasons
Interesting. The majority of these have little if anything to do with technology. Seems to me that IT is again getting blamed for things that are not exclusive to IT, nor are they within the control of IT. Perhaps a better title would have been "5 Unspoken Ways Leadership, Management & Culture Fail IT Projects"?
RunningQuery
50%
50%
RunningQuery,
User Rank: Apprentice
5/2/2013 | 12:52:21 PM
re: Why Tech Projects Fail: 5 Unspoken Reasons
If something can't be done manually why would anyone surmise that automating it will help? Technology can do wonderful things, but it can't magically fix a business. However, it is exciting to spend a bunch of money trying ... you are right Coverlet it is a cultural issue.
UltraShip Tms
50%
50%
UltraShip Tms,
User Rank: Apprentice
4/29/2013 | 3:41:15 PM
re: Why Tech Projects Fail: 5 Unspoken Reasons
From our perspective, the challenges you speak of could all be mitigated if organizations spent a little more time doing due diligence in the selection of a provider/partner of enterprise software. WE categorically preempt these stumbling blocks when selling and then implementing our Transportation Management System (TMS) solution for Fortune 500 companies. Want to know how? We blogged a rebuttal to these five points at our Supply Chain Collaborator blog here: http://bit.ly/10OxtkV Would love your feedback. Thanks Coverlet!
MedicalQuack
50%
50%
MedicalQuack,
User Rank: Apprentice
4/13/2013 | 4:37:31 PM
re: Why Tech Projects Fail: 5 Unspoken Reasons
Ok a little satire here, why do banks always win with their math and formulas, it's this PLOS one study...the fear of math generates real physical pain with consumers...It is an advantage built in, preset for Wall Street:)

http://ducknetweb.blogspot.com...

Now to go a little further and this is important to science as well with "P" values with models and math, we now have a publication that advises how to recognize if someone has "fiddled" with the P Values...we have that financial models..just one more non linear game if you will

http://ducknetweb.blogspot.com...

Again I used to be a developer and integrated some different softwares with medical records and medical billing and even though I am not a quant and being the next level down, a smart programmer can still see and determine were dirty code has been written for profit in just how it executes without having source code.

The Quants documentary is great as it is the only video that I have seen out there that actually helps educate the layman on what quants do and how it works. I have had it on my blog for over a year and keep recycling it as it had about 3000 views when I started and now over 500,000 have watched it. It's the only documentary to where you see a quant at the blackboard and this gives the layman some visual of how this occurs. Wilmott and Derman are great with their explanations. Want to fight crime and fraud, it's all in the models.
Coverlet
50%
50%
Coverlet,
User Rank: Strategist
4/11/2013 | 4:54:55 PM
re: Why Tech Projects Fail: 5 Unspoken Reasons
Steve-

You had me at "oozing."

I'm not sure whether its "the beasts of the industry" that cause the problems or whether it's their size (and ours) that causes them (us) to unwittingly add to the problem. It's never just about someone doing something to IT. There's some delicious complicity there.

CM
Steve Christensen
50%
50%
Steve Christensen,
User Rank: Apprentice
4/11/2013 | 2:09:57 PM
re: Why Tech Projects Fail: 5 Unspoken Reasons
Coverlet Meshing,

Every point you've made is spot on. Can you imagine starting your car, driving to work and only getting there 25-63% of the time? Again, that 2% makes the numbers relevant. My perspective on enterprise technology is that the beasts of the industry: SAP, Oracle, etc. inadvertently cause the problems you've defined.

These systems are complex, massive, expensive, disruptive and tend to totally ignore those parts of the business that make your company unique. The vendors then come in and talk about best of breed and best practices: none of which actually exist. Those two phrases are 100% marketing blather intended to shut you up about your needs because, even though their system doesn't fit your business, your business is obviously out of step with the 'leaders' of the world.

No company starts out to be like its competitors. Every company is trying to bash in the head of their competitors and they don't do it by sinking 5.5% of revenue to acquire an ERP and then 4 - 6% of revenue every year thereafter just to feed and care for the beast. 70% of the workforce of a company derive very little, if any, benefit from the ERP. Instead all the benefits and political capital accrue to the HIPPO that won't be around long enough to see all the carnage.

To avoid technology failure the first step is to take the ERP off the altar and put it into the foundation of the business where it belongs. Freezing its ability, restricting modifications, ignoring upgrades and avoiding like the plague 'integration' is the only way to mitigate risk, budget and resource constraints. To your point about HIPPO's and their ability to move on...you can't move on until the project you sponsored is done.

Now that you've sealed off the oozing source of problems (ERP), use new enterprise technology that does not interfere or require any change to the underlying systems. This technology then must be self contained with sufficient UI, full Logic, infinite Data and fall off a log simple processes that make user adoption instantaneous. My company has been delivering these solutions for 5 years. Projects take less than 30 days. ROI is immediate and the payback is in month 1 or 2 at the latest. User adoption is voracious, training is virtually eliminated and accountability is enforced.
Coverlet
50%
50%
Coverlet,
User Rank: Strategist
4/11/2013 | 12:25:17 AM
re: Why Tech Projects Fail: 5 Unspoken Reasons
Richard-

First, my disclaimer-- which should be published with every column that I write and email that I send: "You're probably smarter than me on most issues and you're definitely more knowledgeable than me on any topic where *you* pose a question. That's not humility speaking. That's an understanding of the law of averages and how it relates to people who 1) read and 2) are engaged enough by that reading to ask questions of the author."

That said....

1) I've found that we chase methodologies-- whether for program management or development-- for all the wrong reasons. It's not waterfall or agile, for instance, that delivers speed to market engineering or reduces inefficiencies or provides better quality. It's culture. Everyone's excited about Agile right now but I know of waterfall shops with soul-- ones that have the right culture and frankly will blow away the more mechanistic, soulless agile shops on any measure. So Agile (or insert any methodology here) isn't a cure-all, its a fad. Culture counts.

2) If you're in a large enough company, there's no *one* methodology that can address the entire array of project planning maturity levels in that org. I always think of that reality show with the family that has 19 kids: the oldest one is 20 years old and the youngest 3 months. That's your modern enterprise. And no monolithic program mgmt methodology or system or tool will offer the kind of differentiated experience that's right for all of those maturity level. As with architecture, we need multiple patterns when approaching project management. And each pattern should take into consideration the maturity of the PM competency of its intended audience.

Given my disclaimer, I'd love to hear what you think is the answer to your question. :)

CM
Page 1 / 3   >   >>
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Elite 100 - 2014
Our InformationWeek Elite 100 issue -- our 26th ranking of technology innovators -- shines a spotlight on businesses that are succeeding because of their digital strategies. We take a close at look at the top five companies in this year's ranking and the eight winners of our Business Innovation awards, and offer 20 great ideas that you can use in your company. We also provide a ranked list of our Elite 100 innovators.
Video
Slideshows
Twitter Feed
Audio Interviews
Archived Audio Interviews
GE is a leader in combining connected devices and advanced analytics in pursuit of practical goals like less downtime, lower operating costs, and higher throughput. At GIO Power & Water, CIO Jim Fowler is part of the team exploring how to apply these techniques to some of the world's essential infrastructure, from power plants to water treatment systems. Join us, and bring your questions, as we talk about what's ahead.