Being in a service business providing computer support and web development, our product is our people’s time.  As our technical staff work on many projects and clients within a week, time planning for their weekly schedule is critical to ensure the best possible use of their time as well as the proper availability for emergencies that crop up.  To manage that in our world, we have implemented a categorization process for the types of work we perform and track what percentage of our time goes into each type.

To begin, we examined the work we did over a 12 month period and determined that the work was either recurring scheduled, planned projects, or “pop-up” work that occurs during the week that we didn’t know about ahead of time but had to handle.   I’ll refer to those types as Scheduled, Project, and Pop-up for the rest of this article.

As expected, the scheduled work we had a pretty good handle on and could calculate how much of our week would be dedicated to that.  The piece we had the least control of was the Pop-up work as these types of requests would come from our clients as they had issues or needs that couldn’t wait until their next scheduled visit.  While that was unexpected work, we found that on a week to week basis, the percentage of our time that this took was fairly regular.  So now we had two of the three variables somewhat accurately calculated.  But what about the project work?

In a client oriented network support and web development business, it is unrealistic to expect that your technical people will be 100% billable unless that are working on long term projects or placed full time at a client.  We use 80% as a target for our people which helps to account for vacations, personal time, internal meetings and training.  With that target, we need to figure out how much Project work we need to fill the gaps between the predictable Scheduled work and the peaks and valleys of the Pop-up work to hit our billable goals.

In planning the workload properly throughout the week, we have increased productivity of the individual engineer’s and developer’s as well as managed the workload to avoid missing SLAs or burning out our staff.
Additionally, proper management of the different work types has led to higher billable ratios and happier workers.  All around, it has been a win-win.

One of the most common things I hear when I meet with small business owner to talk about technology is “I just want it to work”. You didn’t start your business because you wanted to design and maintain a computer network or a web site, but you have come to the realization that you can’t do business without them.

According to this article in Technology, Inc magazine the top ranked concerns for small business are:

• Using technology to reduce costs in other areas
• Stretching the lifespan of your hardware
• Finding vendors that can understand their company and tailor solutions to fit their needs

My Dad owned a small business, and I saw him struggle with the same issues. That makes it very personal for me to provide resources for my clients that my Dad didn’t always have, and to be able to save them from making some of the mistakes he experienced.

Not every technology investment is a good one, but the ones that make sense can really pay off. For example, when personal computers were just making their way into the business world, Dad saw a demonstration of the “paperless office” concept and immediately saw where using computers to gather information once, store it electronically, and move it from order taking to production to delivery could save time and prevent orders being lost along the way. His return on investment came quickly as less people handled an order, mistakes were reduced saving material and labor to redo orders, and the gap between taking an order and receiving payment was greatly reduced.

This positive experience led to a misconception that all technology investments would be great for business. I’ll talk about examples of failures in future blog posts.

What can you do when facing these concerns?

• Take a close look at your business. Ask employees how they spend their time and where they see bottlenecks. Is there a way to automate process?
• Weigh cost and risk. If the hardware and software can handle your needs for another year, then hold off on the replacement, but don’t skimp on maintenance and keep the hardware under warranty. These two steps can prevent unexpected and costly downtime.
• Find a technology resource that you trust and talk to them about your whole business, not just your computers. The more they understand what you do, how you do it now, and why you do it, the better their recommendations can be.

One of the most rewarding activities when working on a website project is “pressing the button” to make the site go live. Here at ForeSite we have a virtual “gong” that we bang whenever a site launches, usually followed by high-fives and handshakes.

However this activity doesn’t work as well when the launch requires a DNS change, as is often required when taking over the hosting of a new site. Most DNS changes take about 24 hours, though some networks may get the change earlier than others.

This makes pinpointing the actual “launch time” of a new site difficult. If the site uses a database that is being migrated this issue is compounded by not knowing when, exactly, the database can be cut over.

One solution: Putting an “Under construction” or other placeholder page on the old site while waiting for the DNS change to take effect.

The problem with this solution is that you may lose some visitors who may choose not to come back, and, quite frankly, it seems unprofessional.

Better solution: Use Apache proxy to “fetch” content from the old site, allowing you to cut over the DNS entries early. Then, at launch time, simply remove the proxy.

This solution will allow you to know exactly when the site is live because you have complete control over the cutover.

To do this, using Apache, do the following:

Ensure Apache has mod_proxy enabled

Using your favorite text editor (I like vim), open the httpd.conf file and look for mod_proxy.so. Ensure that the line LoadModule proxy_module modules/mod_proxy.so is enabled. If it is not, enable it.

Setup your hosts file

Again using your favorite text editor edit your /etc/hosts file on the server the new site will be on. Add an entry with the website domain (www.mydomain.com) with the IP address of the existing (old) server.

Add your virtual host

If you do not yet have a virtual host setup for the new website, create it as you normally would, however you will need to add two lines to the virtual host to add proxy support.

Your full virtual host will look something like this:

<VirtualHost 192.168.1.10:80>
ServerAdmin webmaster@mydomain.com
ServerName www.mydomain.com
ProxyPass / http://www.mydomain.com/
ProxyPassReverse / http://www.mydomain.com/
DocumentRoot /app/production/mydocument/www
ErrorLog /app/logs/production/mydomain/www/error_log
CustomLog /app/logs/production/mydomain/www/ssl_access_log combined
</VirtualHost>

Restart apache

Restart apache to pick up the virtual host change (using apachectl graceful).

Testing the proxy

Testing requires a little more effort on your local machine. If you are using Windows, open c:\Windows\System32\Drivers\etc\hosts in notepad.

Add an entry at the bottom for the domain with the IP address of the new server.

Using your web browser, visit the domain. If you see the old site everything is configured properly. If you see the new site, or have an error, something is wrong.

Remember to remove the entry from your own hosts file so you don’t get confused later.

Making the change

Now that you know the proxy is working, you can now change the DNS entry for the domain. Change the A record for the domain to be the new server.

After about 24 hours the DNS change should take effect everywhere.

You now have control

You now have complete control over what a website visitor will see when visiting the domain name. Though the user sees the old site, all of the traffic is going through the new server. You can disable the proxy at any time to make the new site “live” at exactly the moment you specify. To do that, remove the two proxy lines from the virtual host entry, and then restart apache.

Downsides to this method

There are two downsides to this method:

1. Your servers are taking on the load of all requests to the old site, and you probably haven’t started billing for hosting yet. This may not be a huge problem if the site doesn’t get a lot of traffic.
2. Logs (and log based analytics) will show the wrong data on the old server. This is because all of the “requests” will appear to be coming from the new server. If analytics from the old site is important, ensure that Google Analytics is on the site (or another javascript based analytics system), as this type of analytics is unaffected by this process.

As I am finishing out my Executive MBA program at the University of Connecticut School of Business, I have started thinking of themes for 2009 that I will employ to fill up all of my newly found “free time”.  One theme is “learn how to be a father to my first born daughter”, now 4 months old, but writing about that would be much more than a simple blog post and so far, I am no expert. A theme that applies better to ForeSite is “Turning Data into Information”.  We have spent many hours and thousands of dollars creating and updating systems that track all sorts of data.  The problem is that we, like most companies, never turn it into useful information for our business.

I will have several posts about the successes of this undertaking throughout the year, but some examples of places I am looking to achieve results are:

1. Looking more closely at the profitability of certain product lines, and even certain clients
2. Figuring out the best areas to focus internal training efforts based upon the success of past projects
3. Evaluating the health of our client base using certain metrics and measures that can be regularly calculated
4. Looking at how our workload flows between recurring scheduled work, project work and work that crops up day to day so we can better schedule and plan our technical staff on both the web development and network support teams

We have painstakingly gathered the data to properly derive this information, but the act of actually mining it is what’s next on tap.  By integrating what we have built into our PHP web based production system called HaTS and pulling data from other systems such as Quickbooks and ADP payroll I will have much better tools for managing the growth of ForeSite.  You can most likely do the same with varying levels of effort based upon what data you have collected over the years in your business.  If you start looking, you’ll probably be amazed at how much information you have hiding in data that you are not putting to good use.  Stay tuned for what we find!