It is hard to run a business without paying attention to IT at some level.  The required amount of work might be as simple as keeping up with a couple of subscriptions to websites.  On the other hand, it can be as complex as running a team of thousands.  Although IT provides several options, the cost of technology in solutions is often estimated incorrectly.

In these cases (and all points between) one of the most important factors to keep in mind is cost.  The cost in both time and treasure.  The world of IT provides many options.  There are going to be solutions that are too cheap and will never support your business. Alternately, there will be solutions that are too complex and expensive.  Either of these can 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 quickly to you.  However, for those non-IT people in the world, let’s look at some areas of research to determine if a solution is right for you.

Build vs. Buy

Whether to create or purchase a solution is one of the oldest questions man has faced.  Does it make more sense to create a solution customized to my needs or to buy one that may not be a perfect fit?

The IT world tends to make this question even more complicated because there are so many “buy” options available that have a “build” component to them.  The “buy” portion may be a customization of features or full blown development needs.  However, in both cases, it puts an additional twist on the two primary options.

Where to Begin

The easiest way to address the build vs. buy dilemma is to start by evaluating whether each option is valid.  Some businesses are under-served by technology.  These either do not have useful products available or the business is too complicated 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 requires a heavily customized solution allows you to build not only for yourself but others as well. This approach can be a way to turn a cost into a revenue stream.

Many products started out as someone trying to solve a particular problem for themselves.  They found out their solution was valuable to others that needed the same problem solved.

Building a Solution

When creating a solution from scratch, you may not have the staff or problem-solving experience to be able to complete the project.  I think this is a mistake many people make.  I have had numerous clients that started building a solution and found they did not have the resources or budget to complete it.  There are a lot of details involved in software development 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 precise requirements.  A lack of clear requirements can lead 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 and decided it was ready to be built.  This approach helps to get the vision to a form that allows it to be shared.  However,  there are some screen related questions to be answered that do not appear 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? (e.g.,. enters data wrong or leaves the page before it has been filled out)
• What is a requirement 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 step is where the details need to be thorough and complete.  A few wrong assumptions by the implementors can result in weeks of wasted time and money.  That waste alone can be enough to kill projects that either have a tight budget or narrow window of opportunity.

Hidden Costs

Hidden costs are one of the toughest areas to address in any assessment.  The cost of technology in a solution cannot be estimated until solid details about the project are defined.  Once you get beyond things that can be invoiced (cost of goods, licensing fees, etc.), where should you look for hidden costs to be taken into account?

One approach that can be very eye-opening is to do what I call “A day in the life.”  This method is where one either discusses or observes (observation is best) the typical routine of those that are the targets for the project.  The input is not from the stakeholders, but the end users.  If this a solution for customer service reps, then look at their typical day. If it is for accounting, look at their day.

Shadowing Users

A single day is a start, and then you look for “special” days like month end, seasonal peaks, etc.  These peaks often hide work that only occurs 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.  These are tasks that are prone to human error, and that can potentially be eliminated.

Double entry is often uncovered 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 various applications.  This data entry is not only time consuming and error prone, but 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 “that’s the way we have always done it” response 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, work that there is almost always a payoff for regular process review.  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 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 remain as they are, you can also find savings.  This review can highlight areas where you can invest in a solution that is essentially for free due to the savings it will produce.

Finding Help

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.  It is also useful to get a professional, experienced developer to provide a project assessment.  This evaluation will point to where the design or expectations may need to be adjusted.

Project assessment 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, feel free to contact us.   You can contact us directly at http://rb-sns.com/RB/contact.php.  We look forward to helping you get started on the right foot.