Standish Findings By Year. Updated for 2009 report.

http://kinzz.com/resources/articles/91-project-failures-rise-study-shows

This is sobering news for IT managers who embark on in-house software development projects. Documentation that warns against this approach is voluminous. So, why are so many organizations still attempting these projects, and why are we discussing them?

First, it’s important to understand that three criteria must be met to set the stage for successful in-house development. These are: 1. Unique new functionality is required, 2. No Commercial Off The Shelf (COTS) solution is available at a lower cost, and 3. Belief that in-house expertise can support and maintain the solution. If all three of those criteria are not present, then an organization should avoid pursuing an in-house development project. Why are we revisiting a topic that has been discussed and researched for decades? Because we still see organizations that deploy in-house projects without all three criteria present.

Deciding on the right path begins with consideration of a fundamental principle of business.  What is the core function of your organization? Success comes to organizations that keep their focus squarely on the core business. If your organization provides a service for a fee, then the argument is that you should focus on delivering that service more predictably, with higher quality, and at a lower cost than your competitors.  If your organization can do this, your likelihood of success and of generating profit is much higher. Conversely, organizations that allow resources to be applied toward tangential pursuits compromise attainment of the core business goals. Keeping your eye on the ball then, is key to winning the game.

Let’s suppose that you’re in the business of providing connectivity, dial tone, Internet access, remote backup services or any of the other myriad services for which you can charge a monthly fee.  We all know that customers are not incredibly tolerant of disruptions of service or poor quality of service.  They are quite likely to jump to another provider if they think they can either:  a) get the same quality of service for less money from another company, or b) get equal or better quality for the same amount of money as they are currently paying your organization.

Due to this focus on minimizing customer churn, smart organizations have implemented software to manage and monitor the infrastructure gear that’s necessary to be able to deliver these services.  Historically, Telcos and SPs have been very device-centric when it comes to monitoring and managing equipment.  There’s a movement afoot to focus more on monitoring the service (think the ‘basket of technologies’ require to deliver the service) versus monitoring the individual devices.  The most appropriate terminology for this concept is Service Assurance.  This is a topic that we discuss in a number of other blog posts, so I will not elaborate on it in this post.  The question is, how do they do this?  If you break it down to the most fundamental level, organizations have a choice of building this capability themselves or buying software that already provides this functionality (e.g. COTS software).

Earlier I mentioned the risks of the in-house approach. Let’s examine this a bit further by looking at a typical scenario – I’m sure this will sound familiar to many of you.

In-house development is typically done as a side project.  A decision is made that something can be put together in a couple of weeks or a month that will fulfill a particular requirement.  Once that’s done, more functionality is added to address more needs and more requirements.  Pretty soon, instead of doing this on the side, it becomes quite consuming.

Does the software do everything needed?  Typically not.  Do other folks request new requirements for the functionality? Absolutely. Can the in-house proponents respond to these requests quickly and efficiently?  Typically not  – remember, this is a side job.  Does the in-house team have the experience and expertise to turn this software from being a point tool to an integrated system that can tie into inventory, provisioning, billing software, CRM software, etc?  Not really, but sometimes they try.

When things are good, they are really good.  When do problems start occurring? When the inevitable happens: the person who architected or wrote the code gets a better job offer elsewhere.  We see it all the time. At one of the biggest credit card companies.  A large optical backbone provider.  We’ve seen it at InterExchange carriers.  All it takes is one other company in the world to offer your guy a modicum of a raise and the company is left holding the bag.

As Service Providers place more focus on Customer Experience Management and Service Assurance they have begun to acknowledge that they don’t have the software that they need.  The question is, do you build or do you buy? We’ve observed that building is too often a short-cut to a dead-end. Buying is the only way to mitigate risk and keep your resources keenly focused on core business activities that grow your bottom line.

Build it, and you’re done. Done-in, that is. The only fast track to infrastructure management nirvana is acquiring a proven and supported software solution built from the ground-up to deliver quickly on your current needs, and grow with those in your future. And with buying, the future is yours to keep.

Cheers,

Jeff