The Fundamentals of building Client Networks

Recently I've been thinking a lot about the best way to help my clients understand and engage with their IT networks and systems. I have also been thinking a lot about how to best manage and look after these systems for my clients in a sustainable way. In order to do this I've been looking at the fundamental basic building blocks of my client base and considering the commonalities. The reason for understanding these commonalities is to put into place simple guidelines for developing and maintaining a network. Each network will of course have certain unique circumstances but if the fundamental infrastructure is well understood, these unique aspects of each network will be easier to manage.

So thinking of all of these things, I've looked at the commonalities in my clients and found they can be grouped into several broad categories:

• sites with a single server, single location and a small (less than 30) number of users. They may have some mobility but generally only a small requirement.
• sites with multiple servers but only a single location and between 25 and 50 users. Again, some mobility but not a lot - potentially they'll want more.
• sites with multiple servers, multiple locations and 25 plus users. Requirements for mobility including file access and remote VPN access.

Although these categories are quite broad, they cover 90% of the small to medium business clients I tend to deal with. These clients are all important to me, and given I have a finite amount of time to work with them, its critical that understanding the fundamentals and underlying structure of the networks doesn't need to be re-discovered every time I'm on site. How then to ensure efficient support of clients?

Firstly by grouping sites into the broad categories I mentioned earlier, I have a quick higher understanding of each site. By building each network following standard procedures there is plenty of efficiency to be gained and also it's a lot easier to explain to a client what is on their network.

Secondly good documentation is key. It's not just writing stuff down, but having it available to review when you are onsite - and this means there are several things that have to be in place:

• data must be available via some sort of mobility
• data must be secure
• data must be organised and detailed

Having the data secure is incredibly important - if it's available using some type of web interface, it has to be SSL secured and the passwords have to be strong. Although this seems obvious, it doesn't seem to be well executed. Having data organised and detailed is the key to keeping client networks well looked after.

Thirdly using the same basic ideas to build each network type mean that if the key support staff member is not available, other support staff can easily work out what is where and how it's set up. These basic ideas also make it far more efficient to produce quotes and proposals, and, I've found anyway, that development of new ideas can be more easily implemented into proposals and integrated into networks.

Recently I've noted that lately I have been speaking with businesses that aren't currently clients of mine and I've found some over-complicated and under-documented networks. By applying some of the basic principles I've touched on in the post I'm able to start getting these networks back under control. I've found that the easiest way to do this is the following:

• determine what the client needs
• determine what the client wants
• determine what the client already has
• determine what the client actually can have
• document it all and discuss at length and in as non-technical a manner as possible

These are the fundamentals of building client networks and they are also the fundamentals of recovering a client network from a state of disrepair. The major difference is that the former causes a lot less pain than the latter.

Questions?

AB out.