Status

Sure, you've heard of Agile Development, but how about Agile Operations?

I just made that up, actually (the second one) but it seems a fair description of what ASU CTO Adrian Sannier is attempting with the university's new ERP system roll-out according to this Wall Street Journal article.

Reaction so far has been mixed. Chris Murphy at Information Week asks if Sannier is a prophet or a crackpot but I get the sense it's a rhetorical question (especially when he follows it by asking if Sannier would still have a job if he were at your company). Oracle thinks it's brilliant, but then, they had a hand in it. As for me, I have seen some merits in this approach for a while now. I think there is some advantage to making incremental but rapid deployments in some operations, devoting resources to rapid troubleshooting and resolution--a process which is nearly always successful--rather than to predictive failure modeling--a process which almost universally is not.

Sannier's own blog has an interesting series of posts on the implementation itself, and much of the logic behind it, but doesn't specifically address these issues.

Personally I think singling out the agile approach as the culprit here is a bit extreme--we hear these same sorts of anecdotal stories all the time about failed IT projects (for Krigsman's article on this particular project failure, see here--I would have expected that he, at least, have a little more sympathy in the matter), many or most of them managed with traditional tried and true (ha!) test-as-you-go waterfall methodologies. Why you would single out a different management approach as the primary cause of this failure is beyond me; at least the guy has the sack to try something different. As a commenter on Murphy's blog says:

System replacement is extremely difficult. All of the system replacement projects I have worked on that were successful were incremental to some degree. The primary problem being that you not only have to replace system functionality that was there on day zero of the replacement project, you have to also incorporate all of the changes that occur to the business and underlying system while the project is in progress. This means the faster you can deploy, the less additional scope you take on during the project.

Personally I think much of the ire that Sannier's approach has drawn stems from the un-apt comparison of his approach to Google's "perpetual beta" model of software roll-out, but I think there are important difference between a beta and an agilely deployed system. Or maybe not; I suppose it depends on your definition.

I think the real issue, if you want to take something broad and meaningful away from the whole controversy, is about summed up in this quote at the end of the Journal article:

"Everyone knows there'll be problems when you institute new computer systems," says Toni Genalo, who directs data collection for the psychology department. "We were prepared for that. Just not at this level."

If you really want to address these sorts of problems, think about why it is that "Everyone knows there'll be problems when you institute new computer systems." It seems that has become so accepted that we have stopped asking what it is about these projects that have traditionally made it so, and instead (and in doing so, to steal a quote from Krigsman, who stole it from someone else, "Rearranging the deck chairs") started nit-picking which approach to failure has been taken.

If you operate often in the SMB market, then you frequently come across some pretty outlandish systems and setups that various companies have in place. These are usually pretty frightening to anyone with any industry-informed idea of standards and practices. But it is worth remembering, as Nick Carr points out in this article, that for the most part, those systems are there because they work for the people who developed them (no matter how hideous they may appear to trained eyes).

That's a challenge for formally trained consultants, and may be an area where the independent tech who has worked his way up the ladder has an edge in actually meeting the needs of the small business without exacerbating their problems. Of course, as you well know if you have read anything else at all on this blog, I am not a big fan of that bottom-up approach, where cool bits and pieces of technology are added in to a system until eventually it winds up in a massive knot that has a huge price tag associated with untangling it. Still, it serves as a powerful reminder that when we analyze a situation and recommend a solution, it has to be a real solution to some basic business problem (in the scenario above, reducing time taken for data entry and synchronization for distributed reference... there should be a standard catalog of those common basic business problems, shouldn't there? Maybe there is and I should have gone to business school. Or maybe I should write one if there isn't, to help people recognize what they are really looking at hidden behind various other symptoms), not some stock technology fix that happens to be all the rage on IT blogs that week.

At the same time, while "Fat Guy's" home-brew synchronization solution has worked out well for his needs, I have come across plenty of SMBs who have set up similar piecemeal solutions which are actually less efficient than manual solutions, or some packaged alternatives that consultants like me might recommend (including Salesforce). This happens because either, A: they have been told technology is the salve to all their organizational ills, or B: they like cool toys and don't care so much about efficiency. That's a factor not to be disregarded in this sector--it can explain a lot of otherwise inexplicable systems you come across where you think, "Gosh, a pen and a piece of paper would be ten times faster than this." And it can explain why a low-end tech support guy finds more traction with certain types of clients, because he's willing to sell them the easy, short-term fix that feeds into what they are familiar with.

So it's important to be able to distinguish between the two types of situations, and understand whether or not any resistance to your proposed solutions is due to you messing up a working simple system, or whether it's simple inertia. People don't like change, often even when change might be for the better.

Ramon Ray poses this question in a new posting up at Smallbiztechnology.com:The "Small Business Label": Knowing What Is and Isn't For You?

It's a good question and poses quite a quandary for many SMBs as they look to purchase the appropriate products for their technology leads, and it's a question that is often answered very poorly if the contents of most small business server rooms I see are any indication; they run the gamut between toy-like home-oriented products and big-ticket enterprise-grade machinery. In the first case, the device will either lack functionality the business needs or break in short order. In the second case, the business spent way too much money for a product overbuilt for their needs and with exotic features they will never use.

Oddly enough, it usually doesn't seem to matter whether the business had any IT staff or not when they made the purchase. Purchasing is one of the more esoteric bits of expertise in the IT field and few small business specialists have gotten as far as mastering it yet. They, as much as non-IT executives, are as likely to buy based on their personal preference for either low cost or big toys, instead of a taking a more measured approach to procurement.

Ray identifies another cause of this malady in his article--rebranding. He cites this Forbes article detailing how major manufacturers and retailers have been taking existing products and services and simply relabeling them as "SMB specific" to tap into what is viewed as an expanding market.

So how do you sort through the chaff to find what you truly need and makes good economic sense? Ray identifies three components to evaluate whether or not a product is truly "SMB" and I think they are all good indicators:

• Simplicity
• Price
• Support

A product must be simple to install, use, and administer for most small businesses. Monstrous Cisco enterprise grade systems don't fall into this category, with hundreds of configurable options, and a massive certification system built up around their installation and administration. An SMB can't afford the sort of expertise required to run such a system and it won't see much advantage from all that configurability.

Similarly, the cost involved for something of that nature will be excessive, requiring a far larger slice of the budget than the functionality should reasonably cost. At the other end of the spectrum, a home-grade Linksys plug and pray box won't cost hardly anything--but there is such a thing as paying too little, as well. An SMB branded device should fall somewhere in the middle.

Finally, support needs to be available. As above, if you find yourself paying too little, then support probably won't be readily available--it has an associated cost, after all, which the manufacturer is not simply going to eat. And at the high end, support contracts can cost thousands of dollars a month--more than the service will be worth. SMBs, without many technical resources in-house, need to look for products and vendors who offer low-cost or free support, but which is easy to access and helpful to use. A product truly aimed at the SMB market will offer this, and often also foster a user community of sorts (I will take this opportunity to plug AdventNet here, a company which provides a variety of ticketing, tracking, and network management software aimed squarely at the SMB market. In addition to meeting the above criteria of Simplicity and Price, they have a vital and helpful user community on their site forums, who can be immediately and impressively helpful, all at no cost), which is another resource for support.

I don't see purchasing as one of the major crises in SMB IT management just yet, but it has always been a sort of minor scandal, and if you have an opportunity to examine your own purchasing practices and clean them up, these guidelines aren't a bad place to start.

Dell has been rolling out some heavy new initiatives aimed at reclaiming their stake in the SMB market (not that it is in any danger of falling too far behind there, if my observations of local server rooms is any indication) and the latest appears to be aimed squarely at one of the growing challenges for small to medium businesses: storage.

As this CIO Magazine article suggests, this is neither isolated to small businesses, nor is it a trivial matter. The information is not without value, provided it can be stored and mined in an organized fashion. But most storage solutions on the market have not been priced or marketed to SMBs.

Dell's new entry, the MD3000i, starts at around $7000 and runs up to around $13,000 for the full package of drives. Infoworld reviews the device, positively,here.

Dell may be on to something at that price point--IBM, which has been courting small business rather heavily of late, has their own "SMB" oriented storage solutions. But you pay the Big Blue premium, shelling out around $40K for the same 1TB of storage that Dell gives you for around $10K (I've never really understood IBM pricing--yeah, it's better stuff, but it's not that much better, and frequently the better bits are overbuilt for actual SMB requirements; a lot of good stuff you'll never use).

I was definitely among those who wasn't sufficiently thinking through long-term storage requirements three or four years ago, and many of the five-year servers I recommended are still chugging along just fine as far as processing horsepower goes, but they're running out of space. This could be the easy solution for my clients and others in that same boat.

I don't know why this slipped my mind previously, but I've taken over writing for the CIO Weblog recently. I've followed that blog for quite some time, under the able previous authorship of Prashnath Rai, and you may recall the occasional article here citing some or the other of his posts. So it's a rare pleasure to be able to step in and continue writing for it while he moves on to other endeavors.

So--get over there and drive up my traffic numbers!