naach na jaane aangan tedha<\/p>\n
Aada theriyadhava koodam konal endralam<\/p>\n
\u00c3\u0081rinni kennir illur r\u00c3\u00a6\u00c3\u00b0ari<\/p>\n
Buruk muka, cermin dibelah<\/p>\n
Alt\u00c3\u00ad\u00c3\u00b0 bagir illum barni okkurt<\/p>\n
Z\u00c5\u201aej baletnicy przeszkadza r\u00c4\u2026bek u sp\u00c3\u00b3dnicy<\/p>\n
Whether the proverb is Hindi, Tamil, Norse, Malay, Farose, Polish or dozens of other languages and cultures the result is the same: A bad workman blames his tools.<\/p>\n
We are faced with a financial meltdown the likes of which most currently-working people have never experienced. We’re faced with budget slashes, and across the board those that have been generally insulated from economic pressures are now feeling the pain. Those that aren’t usually insulated thusly are probably unemployed, underemployed, or in similarly dire situations. People that have to-date been frivolous are having to rethink. Organizations that bleed capital are pondering surgery. Localities are looking at cuts that transcend “austerity”. Given all of these truths, it\u00c2\u00a0 amazes me how much people are spending and moreso (and more depressingly so) how little people are innovating.<\/p>\n
Innovation: The Missing Link<\/strong><\/p>\n Organizational people are generally good at looking at numbers and figuring out where to pull money from. See a fat account with “low value”? Raid it. See a moderate account with “moderate value”? Tax it. See a way to provide “pain” while stoking the “poor me” fires? Twist it… hard<\/em>. Organizational people are generally piss poor<\/em> at finding, recognizing, or rewarding innovations that not just save money, but provide enhanced value. The reasons for this vary and are less than simple, but it comes down to knee-jerk reactions: Organizations spend if they can and raid if they can’t, instead of challenging what they spend (thus encouraging innovation) and weathering the inevitable lean times without too much constraint.<\/p>\n In these tough times, innovative consultants are in unprecedented demand to look at processes and fix them; To analyze inefficiencies and correct them; To trim recurring expenses (read: license fees) at the expense of initial productivity hurdles; To point out possible organizational innovations (the surprising, subtle, and obvious alike) and provide direction.<\/p>\n Innovative people can leverage innovative technologies and spread very little money very very far. Whether it’s saving $400,000\/year from licensing your operating system and database, or tossing beanbags and boardgames for your customers to destress with during critical periods, innovations matter.<\/p>\n The most common excuses I’ve heard for not innovating are tool-blame. The word “tool” is loose (as it is in the proverbs). “It’s my job to do X, so X+1 isn’t my problem.” “Our organization uses Pricey Fuzzy Widgets, and retooling to use Cheaper Shaved Widgets would be inconvenient.” “We can’t innovate X because we have to do Y.” Where those maintaining the status quo see their job description as a hurdle, innovators see lack of ambition. Where the novice sees impossibility of retooling, innovators see enhanced value and long-term savings. Where the naysayers miscorrelate requirements, innovators see new platforms and migration paths.<\/p>\n I’ve mentioned “enhanced value” a few times here (and elsewhere). That’s an important term when talking about innovation. Not all innovations are about saving money. Some of the best innovations are about “enhanced value”: e.g. You spend $100\/month on cable TV, for 4Billion Channels. Satellite TV offers 12Gazillion Channels for $100\/month. So instead of allowing your Department of Redundancy Department to go buy Flashy Amazing Product for $1bajillion, require them to work with in-house development to figure out what they need<\/em> and how much that would cost to develop.<\/p>\n Buy vs. Build vs. “Buy Free”: The TCO Debate<\/strong><\/p>\n If you’re not big on understanding technology or have more money than innovative ambition, you probably love cutting checks to vendors for “superior”, “polished”, “commercial”, “patented”, “Fisher-Price” products. After all, everything “out there” must<\/em> be better than the team down the hall can build it. In your<\/em> defense, perhaps the development team are more “maintainers” than actual “developers” (Said differently: Perhaps they’ll tell you where to shove your project proposal) in which case there needs to be some personnel adjustments. In their<\/em> defense, you probably haven’t really tried.<\/p>\n If, however, you’re not keen on high acquisition fees, recurring license fees, exorbitant training fees, disruptive mandatory updates, frequent bugs that take weeks\/months\/never to be addressed – in-house (or project-sourced) development is a very relevant solution you should really pay attention to. It should, in fact, be mandated<\/em> from the top-down that in-house (or project-sourced) development be considered prior to any<\/em> software\/service acquisition. After all, the Department of Redundancy Department doesn’t care if their $1bajillion Flashy Amazing Product could be developed in-house for $6,000 in already-funded labor, they just love their salesperson and don’t want to have to talk to the “geeky people” – but the Chief Financial Officer sure as hell should. The organization will not only save money but see substantial enhanced value. The Department of Redundancy Department doesn’t really care about either, they just want a new pair of shoes.<\/p>\n When looked at objectively, some services are clearly better bought. Your in-house development group is probably not best suited to build a word processing package, for example, when there are others that are cheaply\/freely available. The in-house development group may<\/em> know of better\/cheaper alternatives to that which the Flash Salesperson is trying to pimp.<\/p>\n “Project-sourcing”, or out-sourcing the work on a project is also something worth considering if true “in-house” isn’t an option due to workload or expertise. The project will be built to your specifications using your tools and can be maintainable by your people (assuming you can write a half-decent spec). Costs will generally be higher than in-house development but especially in a demand market, can become very competitive when shopping the spec around.<\/p>\n Operating systems and database platforms are some of the most universal Buy vs. “Buy Free” savings realizers for most organizations. These costs, while sometimes low-per-unit, get staggering when multiplied across the enterprise and further throughout time as recurring costs. The aforementioned $400,000\/year license cost was for a relatively small 85-server operation (~half of which were database servers, most of the rest of which were application servers). On the same hardware they rolled out a “free” operating system, and an “open” database platform where they paid ~$8000\/year for support. They estimate ~$9000\/year in salarytime above-and-beyond what they used to spend for the “commercial”,”patented”,”Fisher-Price” package.<\/p>\n Understanding those numbers, acknowledging you may need a different level of monkey to maintain a different system, seeing the “Big Picture” and executing a plan like that takes a lot of risk, patience, and innovation. You can’t blame the mirror because you’re ugly, your hemline because you can’t dance, your oars because you suck at rowing, your tools because you’re a bad workman: You have to push through and innovate- Not just because “times are tough” and “resources are meager”, but because an investment in human capital pays dividends, and innovation is almost always the right decision.<\/p>\n","protected":false},"excerpt":{"rendered":" naach na jaane aangan tedha Aada theriyadhava koodam konal endralam \u00c3\u0081rinni kennir illur r\u00c3\u00a6\u00c3\u00b0ari Buruk muka, cermin dibelah Alt\u00c3\u00ad\u00c3\u00b0 bagir illum barni okkurt Z\u00c5\u201aej baletnicy przeszkadza r\u00c4\u2026bek u sp\u00c3\u00b3dnicy Whether the proverb is Hindi, Tamil, Norse, Malay, Farose, Polish or … Continue reading