One of the most interesting features of Apple’s new iPhone 4GS is Siri, a voice-recognition “assistant” that is able to take colloquial spoken English commands. For example you can tell Siri to “book and appointment with John tomorrow” and “she” will check your calendar for available times. There are plenty of reviews of this feature, and that’s not the crux of this article. What is however is that Apple has introduced Siri as “beta” software: a product that the manufacturer believes is complete, but hasn’t been fully vetted and tested on a large scale.

This is nothing new in the technology world, and the preponderance of Google’s free online offerings also fall into this category despite widespread usage. Many other companies in the technology world generate consumer angst when they release what’s perceived as poorly-tested “beta” software to meet a release deadline, co-opting users as involuntary testers in the process and fixing the problems later, however they are usually selling what is billed as “complete” software rather than clearly denoting its beta status.

There’s no harm in a corporate setting to launching some “beta” initiatives, as long as the beta status is clearly spelled out to the user community, and not used as an excuse to release half-baked work for business-critical functions. No one has the resources to pursue every initiative to the fullest, but beta initiatives can test new technologies, or get you 60% of the way there on a problem that needed to be solved yesterday, bridging the gap to a more prefect solution. In short, if you’re not experimenting with a handful of beta initiatives, preferring to do everything “perfectly”, you are probably missing opportunities.

Google’s Motorola acquisition is all over the press, and represents an interesting shift in the mobile landscape. I’ve frequently discussed the changing mobile landscape on these pages, and despite my current enjoyment of the Apple i-products, Google and its Android OS are emerging as the ones to beat in the mobile space.

Until recently, Android’s biggest strength, its adaptability to a large variety of devices, was also a handicap that resulted in incompatibilities between devices. While this is still hurting Android in the tablet space, the kinks are largely becoming ironed out in the smartphone form factor (although still hitting hiccups in the tablet arena). With Google directly owning a hardware manufacturer, this gives them the ability to push new, and potentially more risky innovations on the Android platform.

I don’t think there’s as much risk as some are speculating about Google making enemies of its customers; most of these customers also use archrival Microsoft’s Windows Phone operating system, so in essence they are all ready less chummy than some would have you believe.

For CIOs, competition is going to be a good thing in the mobile space, and as companies increasingly look to the cloud for applications, a cloud-centric mobile operating system will be key. Google’s expanded ability to deliver exciting hardware alongside other Android-based manufacturers should be a win for IT departments and push the industry as a whole, just as Apple knocked the pants off companies like RIM and Microsoft when the iPhone first arrived on the scene. Again, while I’m currently happy in my Apple-centric mobile world, Google’s tribe of manufacturers is iterating and innovating faster than Apple, and rapidly learning from earlier missteps. With direct access to a hardware manufacturer and some “litigation insurance” on the patent front, from an IT perspective, this acquisition looks like a strong win.

I find benchmarks to be of limited use, mostly for "ballparking" rather than making key strategic decisions. If I discover my anonymous "competitor" has 12.674% fewer staff than I do, what does that mean and why should I care? If you find you’re grossly outlying your industry, that might trigger a deeper investigation, but knowing my spend is plus or minus 2.847384% of the industry norm seems to be little more than nice cocktail party trivia.

Where benchmarks can be helpful is in comparing similar IT initiatives. If I’m spending 20% more and taking 40% longer on an ERP project than everyone else, I better have a darn good reason.

Rather than obsessing over benchmarking, I’d expend the effort on making sure you are setting and meeting appropriate internal service levels, building peer relationships, and tracking the results of your IT spend rather than worrying about how you generally compare to anonymous peers.

I’ve recently seen a spate of articles and books predicting the “death” of corporate IT. Cloud, virtualization, outsourcing and a raft of other buzzwords will relegate corporate IT to a dusty display case in the museum of corporate dinosaurs if you believe the pundits.

The problem with most "IT is dead" articles is that they peg a tool as killing a business function. Power tools didn’t kill carpentry any more than the loss of the adding machine didn’t kill corporate finance.

The most effective IT leaders have always been about solving a business problem with technology and process, and for the most part, no one in leadership cared if they used mainframes, terminals, cloud, or the "trained monkeys" someone cited above.

Frankly I think IT leaders do themselves a disservice when they focus on the tools rather than the outcome.

Having spent a number of years in this business, I have seen the good, bad, and the downright ugly. While consulting companies can unfairly be saddled with blame when things take a turn for the worse, there are often subtle “dirty tricks” that allow consulting companies to happily watch billable hours stack up while the client suffers. Here are a few of the worst and most common offenders:

Enabling indecisiveness. Many organizational endeavors (IT or otherwise) fail when decisions are not made quickly and effectively. When you have a large consulting team that likely helps manage the project at hand, they can sabotage budgets and burn cash simply by enabling indecisiveness, and allowing low-level analysts on the client and consultant side to accept any and all scope changes. While not exactly a “Johnny Neer-do-well” level of nefariousness, billable hours tick by unchecked as the consulting team dutifully schedules and attends endless meetings and stands idly by as a three-day decision drags into a multi-month debate.

Going after the “cool stuff” at the client’s expense. Everyone in tech loves the new, exciting and often untried, consultants and vendors included. While every organization should be pursuing some R&D-style experimental efforts, many consulting companies pitch something as “stable” when it is beta at best. Trusting a key process to half-baked systems is a sure way to pump up billable hours, and risk the whole implementation going bad to boot.

Reinventing the wheel. The big firms pitch their methodologies and associated tools and templates as a big benefit and cost saver. Yet, when the implementation starts, they happily rebuild it all at the whims of some midlevel manager who doesn’t like the layout. On a large project, this can easily be a five or six-figure endeavor. Are pretty documents worth that much to your company?

So how does one “stop the insanity?” There is no shame in seeking an outside advocate with no vested interest in the project. For smaller efforts, this could be someone internal who is not connected or compensated for the project’s success, or an external resource who has your best interests at heart. Ideally, this person gains nothing financially when the project stalls or drags on, and is not looking for opportunities to get their implementation team on the ground (I just might know a guy).

Trust your gut when something seems fishy, and above all stamp out “stealth” scope increases and inefficient decision making. Lopping a few days off a project schedule will do far more for your budget than calling in the expense police and forcing the team to stay at the Fleabag Inn.