The Cost of IT

It is hard to run a business without paying attention to IT at some level. This might be as simple as keeping up with a couple of subscriptions to web sites, or running a team of thousands. In these cases (and all points between) one of the most important factors to keep in mind is cost. The world of IT provides far too many options. There are going to be solutions that are too cheap and will never support your business. There will also be solutions that are too complex and expensive that will sink your business through lost time or finances. If you are an IT professional with decades of experience in building and assessing solutions this cost analysis might come easy to you, but for those non IT people in the world, let's look at some areas to assess if a solution is right for you.

Build vs. Buy

This is one of the oldest questions man has faced. Does it make more sense to build a solution customized to my needs or buy one that may not be a perfect fit? The IT world tends to make this question even more complex because there are so many "buy" options available that have a "build" component to them. This may be customization of features or full blown development needs, but in both cases it puts an additional twist on the two primary options.

I have found that the easiest way to tackle the whole build vs. buy problem is to start by evaluating whether both options are even valid. There are businesses and processes that are either under-served by technology and do not have very good products available, or they are too complex for a general solution. Sometimes only a custom solution will fit your business. In these cases there may not be a viable option to buy.

As a brief aside, I do want to mention that sometimes being in a business that requries a heavily customized solution allows you to build not only for yourself but for others. This can be a way to turn a cost into a revenue stream. There are numerous products that started out as someone trying to solve a particular problem for themselves and they found out their solution could be sold to others that needed the same problem solved.

For the build option, you may not have the staff or problem solving experience to be able to build a solution. I think this is an assessment many people make incorrectly as I have had numerous clients that got started on building a solution and found they either did not have the resources to complete it, or they found out the cost was beyond what their budget could afford. There are a lot of hidden details involved in building software that can blow a budget apart even before a halfway usable product has been built.

Analyze the problem

One of the biggest contributing factors to the failure of software projects is a lack of well-defined requirements. Lack of good requirements can contribute to increased cost, longer development cycles, and even improper testing. I see this a lot in cases where someone has sat down and done some thinking about the problem and solution. They got to the point where they put together some screen mock-ups ad decided it was ready to be built. This helps to get the vision to a form that allows it to be shared, but there are a number of questions that have to be answered about a screen that never seem to be included in the sample:

• How does the user get to the page?
• Where can you go from this page?
• Can any user see this page and all its features?
• What are the prerequisites to this page? Login? Other Pages completed?
• What happens if the user does things wrong? (eg. enters data wrong, leaves the page before its complete)
• What has to be done on the page and what is optional?
• How does the user's work get "saved"?
• Does the data on the page need to be refreshed?
• Can other pages be open while the user is on this page?

The questions can go on and on. In some cases a few screen mock-ups turn into dozens, or even hundreds, of pages of details once the requirements are fleshed out. This is where requirements need to be thorough. A few wrong assumptions by the implementors can result in weeks of wasted time and money. This alone can be enough to kill some projects that either have a tight budget or narrow window of opportunity.

Hidden Costs

This is one of the toughest areas to address in any assessment. Once you get beyond things that can be invoiced (cost of goods, licensing fees, etc.), where should you look for hidden costs that need to be taken into account? One approach that can be very eye-opening is to do what I call "A day in the life." You can either discuss or observe (observation is best) the typical routine of those that are the targets for your project. If this a solution for customer service reps, then look at their typical day. If it is for accounting, look at their day. A single day is a start, and then you look for "special" days like month end, seasonal peaks, etc. where there might be work that is only done on those special days. These will also need to be taken into account and can sometimes have more problems to solve than a typical day.

In observing the tasks the target users do, look for areas of repetition, areas that are prone to human error, and tasks that can potentially be eliminated. Double entry is a common culprit in this sort of analysis. A review of a typical day may show that the same data is entered multiple times into a single system, or manually re-entered into multiple systems. This is not only time consuming and error prone, it can also cause problems in data consistency. How often have you come across issues where the data in different systems does not match even though it should?

Think outside of the box...

The "thats the way we have always done it" respone to any task should be a red flag indicating the process is worth a review. Technology and other advancements have done so much to change how business can, and should, be done that there is almost always a pay-off for reviewing processes regularly. If no one can give a good reason for why something is done, then it might not need to be done at all. Lessons learned from doing this may allow resources to be shifted or eliminated and might dramatically change the direction of a new project. A great example I have seen many times is where reports are turned off or not run for a while to see if anyone notices. If no one complains, then that report is a good candidate for elimination. When you step back and take a look at whether things need to be done as they are, you can find savings and/or areas where you can invest in a solution essentially for free due to the savings it will produce.

As you can see, there is a lot more to building software than meets the eye. The costs of time and finances for even small projects often make it more than worthwhile to spend time up front designing a solution and even getting a professional, experienced developer to provide an assessment of where the design or expectations may need to be adjusted. This is one of the services we offer and we always prefer to be contacted before a project begins rather than after it has gone off the rails. If you are starting an IT project and would like us to help you out feel free to contact us at: http://rb-sns.com/RB/contact.php. We look forward to helping you get started on the right foot.