It’s hard to say whether these poor expectations lead to the first mistake— lack of technical leadership—or whether it’s the other way around. There is no doubt that, together, cause a long list of headaches for business.

In the case of the online retailer we introduced two weeks ago (if you haven’t already, go back and read about the technology crisis that almost destroyed 60% of their revenue), the two were inextricably intertwined. They had built their e-commerce platform on Magento, a well-respected open-source (OSS) e-commerce platform—a good choice. But their trouble started with expecting Magento—and its many third-party plug-ins—to operate the way commercial  software does.

Many businesses choose an OSS platform for its greater flexibility, nearly infinite customization, and lower up-front cost, not realizing that it also comes with a unique set of challenges—and costs. Unlike commercial software, OSS generally has no installation wizard. Implementation (and upkeep) requires much more technical expertise and investment. Additionally, usability and support varies widely among software vendors.

The problem is magnified when using third party plug-ins like affiliate tracking software. In this case, the retailer’s plug-in had been purchased from a vendor in Eastern Europe. The purchasing decision had been made by the business unit with no input from the technical team, based on marketing that touted the software as highly scalable, stable, and easy to integrate with Magento.

Unfortunately, because third-party OSS plug-ins are generally not supported by the same vendor that provides the primary platform, integration and support can be complicated… and sometimes disastrous. In this case, the client had no recourse when they discovered—under pressure—these problems:

• The plug-in was incapable of performing as advertised under high transaction volumes.
• The vendor provided no phone support at all.
• Support would provide troubleshooting only after frequent, cumbersome patch updates were installed.
• Emails and chats could be answered only during limited Eastern Europe time zone office hours. Since the client organization is located on the Eastern seaboard of the U.S., this meant that work could only be performed in the middle of the night.

Had the organization’s business leadership been aware of the unique challenges of OSS and third-party plug-ins, better due diligence would have uncovered these problems before they escalated into crisis.

Helix Biz addressed the immediate crisis by allocating significant human resources and performing risk-reward assessments that freed the team from restrictive fears and permitted a quick resolution. Specifically, letting go of the fear of “crashing the system” (since it was already crashed) allowed the team to take some risks that ultimately resulted in solutions that the plug-in vendor missed because they were hung up on preventing damage and unmotivated to find a solution.

With the system up and running again, we focused on building systems and setting expectations to better manage the organization’s open-source assets. Within three months, the client was able to seamlessly change the site’s look and feel, plus add real-time inventory, international shipping, Fed Ex shipping, wholesale options, and an entirely new catalog. Within six months, they had added a rewards program and auto-ship options. Basic changes such as new products and pricing updates are now handled in-house, enabling agile response to market changes. And no third-party plug-in is likely to crash the system any time soon.

Of course, poor expectations were only a part of the original problem, and addressing them was only part of the solution. Last week we addressed lack of technical leadership, and next week we’ll talk about the third major technology mistake that most businesses make: Inappropriate resource planning. You can read more, right now, about these three mistakes and how they impacted this online retail client, in the case study. And don’t forget to subscribe to this blog so you won’t miss the final installment!

Most businesses recognize the need for accounting, legal, and strategic leadership. Long history has taught the market that these areas require specific, professional expertise. Because digital technology, in comparison, has a relatively short history in the business world, it’s less obvious that it also requires a high level of expertise and leadership in order to support the business effectively. As understandable as the oversight is, at best it leads to frustration and an inability to perform up to potential. At worst, it leads to dire consequences.

Last week, we introduced an online retail client for whom the latter had occurred. Their affiliate tracking software had crashed irretrievably, resulting in an angry backlash from the sales force responsible for 60% of their revenue. On the surface, the crisis was caused by a poorly designed and unsupported tracking plug-in to their Magento platform.

At a deeper level, a lack of technical leadership had set the stage for this crisis. Prior to the crisis, responsibility for technical development and management was spread across several internal departments and outside vendors, with no clear structure. As a result, no one department or organization had clear ownership, nor was anyone asking hard questions, performing due diligence, or implementing best practices. When problems arose, communication became tense and business leadership was unable to adequately hold anyone accountable.

Most telling, when company leaders had an idea for site updates or to add functionality, their process was simply to hand the job down to the internal technical leader as a mandate. If the technical lead felt the project could not reasonably be completed to the specified criteria, he would simply refuse the project without explaining why or offering options.

Meanwhile, the external software development team would simply tell business leadership “yes” to the same project, without explaining consequences. The business leadership team had no way of knowing that they were adding ever-more-complex layers of custom coding that, though quick and effective in the short term, carried dire long-term consequences for the business.

Although the site was built on a well-respected and highly customizable open-source e-commerce platform (Magento), this problem had resulted in an increasingly cumbersome system that could be updated by no one except the coders who had created it, effectively locking the business in with a single development vendor. Over time, even small changes such as a catalog update became increasingly complex, expensive, and time-consuming.

Significant updates, like adding the new affiliate tracking software, became a downright nightmare. To make matters worse, lack of leadership meant that no one had asked the critical question: “What if the system fails?” As a result, there was no back-up plan, nor any way to re-install the old system when the new one failed.

When Helix Biz was called in, immediate crisis resolution was called for first. We brought in our technical leadership chops to restructure departments, holding both internal and external resources accountable for their responsibility. We instituted twice-daily meetings to address the crisis, and implemented risk-reward evaluation criteria to cut through the clutter and motivate stakeholders and employees to focus on mission-critical activities.

Within ten days, affiliate tracking was operational again at 94% accuracy. Within six weeks, at 98.5%. Business leadership could focus attention on negotiating with, compensating, and appeasing the affiliate base, while technical leadership—Helix Biz—focused on building the long-term solutions that would support growth. Ultimately, the client not only experiences 99+% up time with their software, but also their platform enjoys an intrinsic flexibility that has allows seamless updates and the addition of significant functionality at minimum cost and hassle.

Of course, technical leadership, though critically important, was only part of the puzzle. Two other major problems had led to the crisis and needed to be address: Poor expectations and inappropriate resource planning. We’ll look at these problems—and their solutions—in greater detail over the next two weeks. You can read the full online retailer case study here right away. If you haven’t already, be sure to subscribe to the blog so you won’t miss the next installment!

How did we accomplish so much so quickly? By addressing three hidden problems that can spell long-term disaster for any organization. You may be surprised to learn that at least one of these three problems exists inside more than 80% of the SMBs we encounter. Is yours one of them? Read on and see if any of this sounds familiar to you.

Can you feel the pain?

The client in question, a niche product retailer with national reach, approached us in the midst of a technology crisis that was quickly escalating to a game-changing affiliate relations disaster. Their commission-based affiliate network represents 60% of traffic into their Magento e-commerce site—and they were on the verge, not only of losing this entire sales force, but of becoming subject to multiple lawsuits. All because of one, simple little technology snafu.

Of course, game-changing snafus rarely are simple, or little, at the core, and that was true in this case as well. This client had long struggled with getting the technology to support their vision of what the company could be. (Sound familiar?)

Now, during the busiest retail season of the year, this ongoing frustration erupted into full-blown crisis. They had just implemented a new open-source tracking system to more efficiently monitor affiliate activity. This would be good news if it had worked properly. However, not only did it not work—it immediately crashed, irretrievably taking down the entire affiliate tracking system with it.Affiliate sales continued to pour into the site, but the company no longer had any means of tracking and appropriately rewarding the affiliates that made it happen. The affiliate sales force, most of whom made their living through these sales, immediately began to lash back in anger. To make matters worse, some of them were threatening to sue. In a matter of days, this fast-growing company had become suddenly exposed to potentially game-changing losses.

And all because they had fallen prey to three critical technology mistakes. You ready for this? Top three critical technology mistakes:

1. Failing to source professional, strategic technical leadership,
2. Embracing unfounded expectations in regard to open source software,
3. And going penny-wise, pound cheap (aka failing to plan human and capital resources appropriately).

Many organization are unaware that they are suffering from these problems until it erupts in crisis. But certain symptoms can provide clues. Any of these sound familiar?

• Seemingly simple technology updates take forever and cost a minor fortune
• You’re surrounded by “yes men” who say they’ll do something but then inevitably take too long, cost too much, and do it wrong
• You’re surrounded by “no men” who resist every technology change you try to institute
• You’re surrounded by both and wish someone would just get the job done
• Nothing, ever, is as easy as it seems like it should be. You know your organization is capable of so much more… if only the technology were more help than hassle!

If you can identify with any of those, odds are you’ll benefit from identifying which of the three critical technology problems you’re suffering from. Next week, we’ll help you out by taking a closer at the first of the three mistakes, what it looks like, how it led to trouble for our client, and what to do about it. You can also read the entire case study here. And be sure to subscribe at right to receive notification when the next installment is posted.

I’ve said it before: It’s easy to point fingers at Amazon (or Microsoft) and show how “the cloud” isn’t all it was cracked up to be.  That would be a simplistic conclusion to make, however.

First off, “the cloud” is not Amazon. The cloud is not any one thing: software or hardware.  In fact, its very definition is variable.  In its simplest form, a cloud service is syncing your Documents folder with a hosted server, as in the case of Dropbox, Box.net, and their kin.  To enterprise-level users, it generally means distributing all your applications and data across many different servers in different regions, with redundant, instant fail-overs.

But for the majority of businesses, “the cloud” is so much more.

Before cloud services became widely available, a mid-sized business of roughly 200 employees would need several dedicated servers to handle their internal services, including:

• Domain management (Active Directory or LDAP)
• Exchange or other email
• Document and file repositories
• ERP, CRM, etc.
• Other internal systems

This infrastructure came with a very high fixed cost in terms of physical hardware, software licenses (beyond the applications themselves), and — perhaps most importantly — the manpower required to maintain them.

The cloud gives businesses more options, not only for features and availability, but cost.  For example, Microsoft offers hosted Exchange plans for as little as $4 per month per user.  For businesses looking to run an eCommerce site, they can have the popular Magento platform installed and running in a High-Memory XL instance for $324 per month!

What’s more, the cloud provider manages the infrastructure.  Did Amazon make mistakes with its Virginia datacenter that cost its clients valuable uptime?  Probably so.  Is your business likely to do any better at avoiding downtime and software bugs at a cost that is sensible?  Probably not.

To be sure, cloud services are not right for every business, and even when the cloud does make sense for your organization, it must be implemented as part of a strategic plan and managed properly.

The cloud is not a panacea.  It is does have its issues and risks.  But it is a very valuable arrow in the technical quiver for mid-sized businesses who rely on technology to drive their sales and operations.

I’m glad that the folks who like to dig into such things are calling Amazon to task over the nature of the outage.  They are asking good questions, and helping to bring pressure on Amazon to beef up their procedures and systems.  All of which will make AWS stronger in the long run.

The mistake is in calling to task the concept of cloud services.  Because for all the headache and downtime caused by this weekend’s outage, the cloud still has a stellar record of providing services that many businesses simply could not manage on their own.

Originally found on Imgur.

The image above is a programmer’s joke about how difficult it is to communicate with non-programmers.  But the reverse is also true.

Almost everyone who has worked with programmers (or developers, as some prefer to be called) has a story to tell about working with an extremely talented person who — despite their technical expertise — somehow manages to miss the mark.

I remember working on one of my first projects as a Product Manager.  We were building a portal where our customers could manage their payroll information.  During one of the demonstrations from the technical lead, we had the following exchange:

Me:     ”Where is the login screen?”
DEV:  ”There’s not one.”
Me:     ”We have to capture the user’s login info.”
DEV:  “OK, I’ll do that next.”

If you’re not a developer, you’d probably expect that the next version would have a standard login prompt.  If the user put in their correct username and password, it would let them in.  If the username and/or password were incorrect, they would see an error.

That’s not what the developer wrote.  See, I said, “We have to capture…”  To capture, in programming parlance, means to retrieve and store.  So while the user was shown a login prompt, all the page did was to store the results in a database, without actually verifying the user’s information or their access rights.

Takeaway

Technical resources don’t necessarily make the same assumptions that business owners do. This is not a bad thing, because that mindset is part of what makes them really good at what they do.

If you are getting ready to invest in a development project, or if you are in the middle of a project and wondering why the project isn’t meeting your expectations, ask yourself theses questions:

• Do I have sufficient technical understanding and experience to work with developers directly?
• Even if I do have a technical background, do I have the time and energy to devote to managing the project?
• Does the vendor have a “business” person who will be working with me to understand my strategic goals and guiding me to make the best decisions?

Answering “no” to these questions indicates that your project is likely to fail.  It may end up working—technically, at least—but the odds are that it won’t deliver the value you need for your investment.

Helix Biz is your trusted technology partner.  Contact us today, and let us take the pain out of  development for you!

Apple’s amazing increase in value is more than just a “rah-rah” story for a turnaround.  Fundamentally,Apple is telling everyone – globally – that there has been a tectonic shift in markets. And if leaders don’t understand this shift, and incorporate it into their strategy and tactics, their organizations are going to have a very difficult future.

What’s interesting to me about this article isn’t the author’s assertion that the “old rules no longer apply.”  That is old news and any business which hasn’t already figured it out by now is already behind on the curve.  My friend Rob Slee at MidasNation calls this new business period the “aggregation age.”

Instead, after showing how Apple and Amazon have used the “new rules of business” to create tremendous value and market share, the author concludes (again, his emphasis):

To be successful you MUST become a tech company.  You MUST be expert in understanding the information needs of customers, and how to supply information solutions that have high value.  And while this may not feel comfortable, it is reality.  Every business must shift, or die.

Now, with my emphasis: “To be successful, you MUST become a tech company”?  In the total context of the article, this may seem like an insignificant choice of words to write a response around, but the author did believe it important enough to make it the headline.  In addition, I believe it speaks to a problematic, yet pervasive, belief both within the tech industry and without.

He’s correct when he goes on to write, “You MUST be expert in understanding the information needs of customers, and how to supply information solutions that have high value.”  But being an expert in creating, managing and delivering information value is not the same thing as being a tech company.  Furthermore, the lack of separation between the two concepts can lead businesses into making bad decisions.  Here’s why:

Confusing process with product

A company which has an Accounting department doesn’t become a financial services company.  Likewise, it’s misguided to think that businesses which leverage technology to automate and control their information systems are tech companies.  Yes, Amazon designed and sells the Kindle Fire, and they certainly are a tech company in many respects.  But Amazon’s primary business is as a retailer, and the purpose of the Kindle Fire isn’t to make a huge profit on the device, but as a conduit to sell more product through their digital storefront.

When businesses lose sight of this distinction, they allow technology concerns and projects to take priority over business.  Often, the strategic goals of the company take a back seat to the growing demands of the I.T. department.

The value is not in the tech

If your business’s direct product is not technology, then you should stop looking for strategic value in tech.  For you, technology is a commodity.

Let’s take an online retailer (not Amazon) as an example.  The technology that makes eCommerce work is a commodity now: from ERP systems to shopping carts and affiliate programs, there are any number of commercial and open-source solutions.  The retailer that succeeds in building tremendous value is not the one that implements the most advanced technology, but the one which has the right business strategy. The business which takes their existing expertise in product knowledge, customer base, marketing saavy, and ability to turn ideas into sales will come out ahead.  This is what has made Amazon successful, not that the Kindle Fire is a great tech product (although it is).

If a business begins to think of itself as a tech company, they can make some very poor choices when it comes to implementing their strategic technology initiatives.  A classic example of this is hiring a technical resource to deliver their automation systems.  Businesses have already learned this lesson when building their websites: hiring a developer to design and lead your web initiative (a marketing effort) may produce a technically successful end result, but it rarely meets the original business objective (more sales).

It’s time for businesses to apply this lesson to other areas of I.T.  If you are looking to hire a technology vendor, and their first set of questions are around the technology itself (such as, “What platform are you on?”) instead of the business drivers for the project, what kind of end result can you realistically expect?

Get out of the technology business

Your market’s landscape changes rapidly, and you need to be ready to change with it.  And, yes, your business needs to understand and adapt to the new “aggregation age” of information marketing.  But even as you change the way you arrange and deliver your core product, the value of your business remains in the expertise and processes that separate you from your competition — not in your technology itself.  So go ahead and build a strategic technology plan and start implementing automation systems that will allow your business to grow profits and reduce costs.

But your company must NOT become a tech company.

1. Clients want useful visibility into the future in terms of costs, timing and deliverables

in fact, it’s almost impossible to be too clear, to benchmark enough and most of all, to overdo the work of identifying forks in the road when it comes to decision making. When a client hires a developer or a company embarks on a software project, they are lost. Even something as complex as building a house is dwarfed by the rapid change, shifting priorities and most of all, the requirement for the new, that’s involved in even a simple software project.

The indispensable software development manager is aware of this and lays it all out for us.

When we at Helix Biz talk about tailoring a plan to meet the specific and strategic goals of your business, this is exactly what we are talking about. Go read the entire article.  It’s well worth your time.

Simple graphics, unlimited options.

The interface is primitive.  Trees, dirt, rocks… even water and lava conform to a singularly sized cube.  The mechanics are elementary: you “mine” the rocks and trees for resources, then use the materials to create tools based on pre-defined “recipes.”   Chop some wood and make a wooden pick. Use that to mine some stone and craft a stone pick.  And so on…

Nevertheless, if my children are any indication, the game is capable of captivating its audience for hours at a time, and transforming the way they view the real world around them. And while the game is not free to play, it openly encourages 3rd party developers to create and distribute modifications to the game, creating new ways to enjoy and play Minecraft.

The power of Minecraft lies in its amazingly open system that empowers creativity and invention. The rules are basic, limitations almost non-existent. My 8-year-old has invented elevators using the movement properties of water blocks, and “televisions” that switch on and off to reveal sheep moving about a pen. My 11-year-old constantly discusses the rules and benefits of the “mods” he will create.

In short, users are free to make Minecraft into the kind of game they want to play. Some like to start with nothing and battle the elements in a survival adventure. Others prefer to turn off the aggressive elements and use the game as a sandbox to create amazing structures like this recreation of Minas Tirith from Lord of the Rings, Hogwarts Castle, or a replica of the Hungarian Parliament building. Personal Minecraft servers allow the game to become collaborative among many households, creating online communities with their own rules, cultures, and ever-evolving villages.

Minecraft has so taken the minds of its fans that fragments of its world pop up everywhere. Get my children together with a few of their friends and it begins to sound like the seagulls scene in Finding Nemo: ”Mine(craft)! Mine(craft)! Mine(craft)! Mine(craft)!” Minecraft themed products populate Cafe Press and Minecraft characters play roles in crowd-sourced Star Wars re-interpretations–all furthering the brand’s reach.

What does all of this mean for your business? Minecraft serves as a model for the potential of your market to unleash its own creative forces on your behalf–if you let it. Many businesses are so worried about their brand, their intellectual property, or the integrity of their software that it is difficult for them to let go and let the crowd do its amazing creative work. But if you’re ready for it, these four principles will help you unleash Minecraft-sized energy on behalf of your product:

* Don’t be afraid of your customers. Use their desire to fiddle and create and interact as an opportunity for powerful collaboration.

* Think carefully about how you limit freedom within your application. Give users the opportunity to experiment, explore, and even modify your product.

* Be laid-back, but not loosy-goosy. Minecraft  would not have survived this long if the product were not robust and capable of handling the creative rigors of its users. Clearly, the basic workings that make the software go are strongly protected from user interference.

* Moderate. Any time you open a resource up to the public, a criminal element is sure to arise. Inside Minecraft, they’re called “griefers” because of the grief they cause other players by stealing their resources or damaging their creations. Griefers never become a serious problem, though, because the system includes tools to identify griefers, and moderators to ensure they get booted.

When Notch developed the first version of Minecraft, he never envisioned everything it would become. Your planned product too has uses that you’ve never imagined, uses that you will only realize when you give your customers as much room as possible to be innovative on your behalf. And that’s how you mine–and craft–for profit.

Why it matters: Choosing between cloud applications versus self-managed systems can be a tough choice for organizations investing in new technology. One of the key benefits cited for cloud is that a centralized platform can be patched more quickly when unexpected things happen—a claim that the Leap-Day outage seems to question. For perspective, however, compare to the headaches for one large POS vendor related to Daylight Savings Time in 2007. The patch took months to roll out over the hundred thousand POS terminals across which it was distributed. Suddenly half a day doesn’t seem like such a big deal.

Why it matters: For all the publicity around their new privacy policy, Google continues to lead the way in big technology transparency and open standards.  And it has paid off: Google is the most trusted brand in America (that doesn’t make iPhones) according to the 2012 Harris Poll Reputation Quotient. The open invitation to break their web browser product, Google Chrome, takes this a step further. While most technology companies prefer to hide their products’ flaws, Google is planning on gaining some very critical security information about theirs using the power of the crowd.  And they’ll be enhancing their public image at the same time.