Product-based Solutions Versus Custom Solutions : Tomb Raider or Genesis?

The Product-based Solution is where most of Corporate America is going for IT today.  The talent required to povide a successful implementation (one you actually renew license maintenance on rather than let let quietly die an ignominious death) requires the tenacity, deep specialized product  knowlege (read arcane dark arts), and courage of a cinema Tomb Raider.  The team required has to know the target product as well as Indiana Jones knows Egyptology; with equivalent courage, problem-solving skills, and morals (one can’t be squeamish hacking a solution into submission) to be able to achieve a usable solution versus an embarrassing product snap-in.   In addition to their product skills the team must be able to quickly navigate the jungle of existing applications with their mysterious artifacts to get the proper integration points and data (Gold! Gold! I say!).

What if the team can’t or don’t navigate your jungle of existing applications or do not know all of the idiosyncracies of the product to be installed?  Well you get an Embarrassing Product Snap-In (Do Not Pass Go, Do Not Collect $200, Do Flush Career).  Every seasoned IT professional has seen one of these puppies, they are the applications you can’t get anyone to use.  Usually because the do not connect to anything users currently work with, or have real usability issues (Harry Potter vs. MIT interface).  Yes, the product is in.  Yes, it tests to the test plan criteria.  Yes, it looks like post-apocalypse Siberia as far as users are concerned (What if we install CRM and no one comes? Ouch! no renewal for Microsoft/Oracle, bummer).

Custom Solutions are more like Genesis, Let there be Light! (ERP, CRM, Order-Entry, you get the picture).  It is a Greenfield Opportunity!  The team you need is just as talented as a Product-based Solution, but very different.  They need to be able to create a blueprint of your desires, like a rock star architect for a signature building.  The team needs to be experts in software engineering and technology best practice.  As well, the team needs to be able to translate your user’s meandering descriptions of what they do (or not) into rational features resembling business process best practice.  That was Easy!

In the case of custom the risk is creating Frankenstein, rather than new life (It’s Alive!, It’s Alive!).  Again, every seasoned IT professional has seen one of these embarrassing creations (Master, the peasants/users are at the gate with pitchforks and torches!).  The end result of one of these bad trips (Fear and Loathing in ERP) is the same, but usually more expensive, than the Product-based alternatives.

Debby Downer what should I do?  Reality is as simple as it is hard; pick the right solution for the organization, Product-based or Custom.  Then get the right team, Tomb Raider or the Great Architect of Giza.

If you’re thinking of acquiring a software startup

IT due diligence on a software startup may seem unnecessary if the core product offering represents a significant new advancement.  It really can’t be overlooked, however, as there are many technology risks lurking within the product and within the company itself.

As far as the core technology offering(s), it’s important to conduct code reviews, architecture reviews, security audits, application performance assessments (especially in light of the projected growth in the business plan) and an assessment of the company’s software development lifecycle methodology.

There are other hidden risks, some of them far removed from the core product offering, that may impact your future acquisition’s ability to achieve its goals.  Many of them stem from the need to be both chief cook and bottle washer during the very earliest days of the company’s existence. Here are the top three:manyhats1

  1. Inappropriate software development practices: My favorite example here is a startup I was advising during its search for first round investors. They could not resist the urge to keep “improving” the code, so they never segmented or froze their brainchild into discrete releases. The night before I had scheduled a potential investor for a demo, they thought of four new “must-have” features to add, and were actually debugging during a demo that failed to execute.
  2. Tendency to re-invent the wheel: Software entrepreneurs are often skeptical of packaged enterprise software to the extent that they will build their own backoffice, CRM, or other applications. The risk this imposes to potential investors is twofold: you are retaining dedicated staff to support those applications, and any migration off of these applications may be difficult because they are often built “on the side” without sufficient documentation.
  3. Project management immaturity:  It’s unusual for a startup to hire real project managers very early on in their lifecycle. While PM discipline could certainly help them during the concept phase, it’s absolutely necessary as they are attempting their first deployments to clients.  Weaknesses in this area are easy to spot as you conduct due diligence interviews with their customers.

So even if the product has no competition in the market place, and you’re convinced it can sustain competitive advantage, please make sure you have qualified resources do some deep probing to help you understand where the hidden problems may lie.

Cloud Computing: Where is the Killer App?

As an avid reader, I have read too many articles lately about how the bleak economy was going to drive more IT teams to use cloud computing. The real question: what are the proper applications for Cloud Computing? For the more conservative IT leader, there must be a starting point that isn’t throwing one of your mission-critical applications into the cloud.

One of the best applications of cloud computing that I have seen implemented recently is content management software. One of the challenges with content management is that it is difficult to predict the ultimate storage needs. If the implementation is very successful, the storage needs start small and immediately zoom into hundreds of gigabytes as users learn to store spreadsheets, drawings, video and other key corporate documents. Open source content management software can be deployed quickly on cloud computing servers and the cost of storage will ramp up in line with the actual usage. Instead of guessing what the processor needs and storage will be, the IT leader can simply start the implementation and the cloud computing environment will scale as needed. My suggestion is to combine wiki, content management and Web 2.0 project management tools running in the cloud computing space for your next major software implementation project or large corporate project.

A second “killer” application for cloud computing is software development and testing. One of the headaches and major costs for software development is the infamous need for multiple environments for developing and testing. This need is compounded when your development team is using Agile development methodologies and the testing department is dealing with daily builds. The cloud computing environment provides a low-cost means of quickly “spinning up” a development environment and multiple test environments. This use of the cloud  is especially beneficial for web-based development, and testing load balancing for high traffic web sites. The ability to “move up” on processor speeds, number of processors, memory and storage helps establish real baselines for when the software project moves to actual production versus the traditional SWAG approach. The best part is that once the development is complete, the cloud computing environment can be scaled back to maintenance mode and there isn’t unused hardware waiting for re-deployment.

The third “killer” application is data migration. Typically, an IT leader will need large processing and storage needs for a short term, to rapidly migrate data from an older application to a new one. Before the cloud, companies would rent hardware, use it briefly and ship it back to vendor. The issue was guessing the necessary CPU power and storage needs to meet the time constraints for the dreaded cut-over date. The scalability of the cloud computing environment reduces the hardware cost for data migrations and allows flexibility for quickly adding processors on that all important weekend. There is simply no hardware to dispose of when the migration is complete. Now that is a “killer” application in my humble opinion. By the way, cloud computing would be an excellent choice for re-platforming an application, too, especially if the goal is to make the application scaleable.

In summary, if your IT team has a short term hardware need, then carefully consider cloud computing as a cost effective alternative. In the process, you might discover your “killer app” for cloud computing.