Small and Medium Business

Seriously there is still a place for tape backup but it’s not in most small to medium business networks.  Here are the problems:

1.  It is not random access so it’s difficult to retrieve single files or folders.

2.  It is subject to degradation easily based on heat and moisture.

3.  The tapes are expensive and wear out.

4.  You must find the same tape drive to read tapes in the event of system loss (theft/fire).

5.  You must restore data separately from the operating system making restoring a complete system time consuming and error prone.

6.  When your technician finds out there is a failure that requires restoring from tape, ask them if there is fear in the pit of their stomach.  Truthful caring one’s will tell you they are nervous.

Tape was the only way we had of reasonably backing up systems till just a year or two ago.  But there are now very inexpensive disk storage devices on the market and great software to take advantage of disk as a backup medium.  These two things make tapes a VERY bad choice for new backup in nearly all cases.   Next installment on the blog….What about off-site backup?.

Every company is similar in one way, they all depend on people to get the work done at some level.  People require communication and communication is hard.  I have had the pleasure of working with and looking deeply into many companies in my career and invariably the hardest thing is getting and keeping people working the way you want and expect them too.  My favorite story is the story of the kids put in a row, you whisper a simple phrase in the ear of the child on the end and ask them to whisper it down the line from child to child being very sure they say exactly what they heard.  They will be rewarded at the end if the phrase the last child heard was near the phrase the first child remembers.  Invariably, even with only a very few children in the line, the last child states a phrase that bears little resemblance to the original.  Now think about day to day communications around your company and you will see time and time again where what you thought you said did not result in the behavior or response you intended.  Now multiply that problem among all the people in your organization and all the times that they depend on each other to answer a “how do I do this” question and you may see the problem in a new light.

One answer to this problem is procedure and policy manuals but frequently it is easier to ask the person next to you to repeat the policy than it is to look it up.  Then you repeat it to the next person that asks and guess what, you have just played the children game in real life.  The first person got the policy from another person and repeated it to you EXACTLY as it was stated in the original document correct?  Well, it is likely that it was not perfect, and so on and so on.

Computer programs are the interactive way of forcing consistent behavior, if the program is written correctly then many of the policies are written into the program and the only way to successfully get the work done is to adhere to the policy or the program stops you and makes you do it.  This is the equivalent of doing the activity with the book open checking that you did it correctly at each step.  One way to solve this problem is to buy the “standard” program or the framework…..these are the programs that were made for your industry or the SAP like general programs that are meant to be customizable to any industry.

I have had the pleasure of looking deeply inside of 100’s of companies in my career.  One of the most uncanny aspects is that even if two companies look like they are direct competitors doing exactly the same thing when you look under the covers they are likely very different.  The differences are, in many cases, one of the reasons why some customers go to one company and some to another.  It may not always feel like this is the competitive edge, but the way you do business affects the way you communicate and that affects which customers you will attract.

A standard program forces you to work in a standard way.  To the extent that your niche is determined by the way you do business you put your company at risk.  For some companies the determining factor is not the data that is kept by the computer, in that case it is very clear that a packaged program is just fine.  A dental office, a doctors office, an insurance broker for a large insurance company that has software, perhaps a car dealer and others are businesses that most likely can be handled by a standard program.

But when you do things a little differently from the rest, and your adamant that this is important to you, then you are a candidate for custom application software.  One of our clients services thousands of clients in small transactions but a competitive advantage is customer intimacy.  How do you seem intimate with thousands of customers?  One of the things we built into the workflow was an easy way to remind the owner to send personal notes to clients on the schedule they were used to and other services to help the owner get that accomplished.   The program that all 100 employees work in every day embodies the rules of engagement that the owner has made a part of every transaction.  New agents coming into the business can not do it any other way.  Training requirements are eased, consistancy is increased and the customers feel the close relationship without it killing the owners time.  She genuinely cares about her customers and now she can genuinely care about more of them.

This is a post about why Application Development has been a big part of my life for the last 25 years.   I started life more as a mechanic, from refrigerators to huge steam plants and journeyman Air Conditioning I loved fixing things.  In the 70’s though I got a job that allowed me to play on an early HP “personal” computer.  Two big cabinets and a monitor and keyboard, single user.  It was an engineering computer and had an early “basic” language on it.  I got hooked but could not afford to do anything with it till years later when the Commodore 64 was introduced.  From then on I could not get away from it.  I programmed early in the morning and late at night.  I taught myself databases and assembler code (the language of the machine itself) and loved it.   Eventually friends asked me to write programs for them and I hacked some things out and made a few bucks.  But one thing I figured out early on, reading the manual and then hacking away till something worked would be fine for awhile but even then there were people developing methodologies and processes to create better programs.  Mostly they worked on bigger programs for bigger companies but the principles were still the same.  So I made it my mission to learn all I could about how “the big boys” did it and bring the relevant amounts of that process and procedure to the work I was doing on small database projects.  In the process I developed a four step process modeled from many of the things I was learning.  I spent hours on the old Compuserve forums learning from the best in the business.  I sent my code out into the world to get criticised by them also.  That was tough, like sending your baby pictures out only to be told they aren’t that cute.  Eventually that changed and I started getting more kudo’s than cut’s thankfully.

Several things I learned over the years.  One, many people who program for a living don’t take the time to learn their craft and they typically have to fix and fix and re-fix problems.  Two, the right amount of project management is required for every project, none is NEVER the right amount.  You must go through the steps of defining what you are going to build, designing the way you are going to build it and then building it according to the design, testing that all the way.  For a small project the time it takes is minimal.  For a larger project, $100k to $500k the process must be more rigorous.  But it MUST be there even for projects you are just doing for fun yourself, or they will fail.  Three, all businesses, even ones that seem exactly alike from the outside, are not alike.  In fact most businesses take on the personality of their leaders and it’s an amazing and fun thing to see.  Four, communication is an art and not easy.  The biggest impediment to communication is the illusion that it’s actually happening.  If you could take a picture of the images in two people’s brain when they were talking you would, I’m sure, be amazed how different they were.  This means that if you are trying to build software, pure idea’s to start with, you have to question, and re-question what you thought you heard in order to get to the real picture.  That is fun and results in very interesting discoveries.  For instance most companies have words they use frequently that mean entirely different things depending on the context but they don’t even recognize it.  As a non-participant though the words cause immediate confusion.  Likely, though, frequently inside the company these same confusions occur but more subtly because people have learned to adjust.  This can be a source of inefficiency and conflict frequently with misunderstanding as to the source.  As an analyst trying to create a model of the business a computer can use I have to be very clear on definitions, computers are not good at situational meanings.  Through this process I have heard more than once, “I know my business better today than I did before you started”.  That is one of the greatest complements I have or will receive.   Last, for now, I frequently see application development that is done by modeling the individual views of each stakeholder and then trying to link those views together.  In fact there is always an underlying model for how the business runs which then can be viewed through various lenses at various angles to show the right person the right information at the right time.  Miss this and the program is inevitably very complex, bulky and not as effective.  Get the underlying model correct and all sorts of changes can occur for years without ever needing a rewrite.

I love teasing out the real underlying model of the business that serves all the stakeholders.  It’s like looking in a fog at first and poking around till you find the substance.  Application development is a passion for me.

Custom Application Development is not for every business.  In many cases there are standard programs off the shelf that can perform all the tasks you need sufficiently.  Of course programs like Microsoft Business Systems Accounting and Quickbooks and many others can and should handle standard accounting tasks.   They are good at it because Accounting is a very standardized process and is unlikely to be your competitive edge.  But small business is a reflection of the management team and frequently of one or two people who start a company.  Just as personalities are different companies are different and have their own personalities.  It is frequently the case that two companies that make competing products or have competing services actually operate completely differently.  In the competition for both customers and great employees that personality can make the difference between mediocre and great success. 

So how does Application Development fit in?  There are operations in many businesses that require a great deal of information and frequently that needs to be acted on by many people over a process.  Getting the right information to the right people at the right time using paper is cumbersome.  Computers have aided that process by managing it and frequently by not loosing the information on some one’s desk or in their briefcase.  But applications that are standardized can not handle the specific personality of your business and if that’s your niche, your competitive edge, then custom application development becomes an option. 

How do you know if this applies to you?  Do you have databases that have sprung up in Access or other personal databases that are now being relied on by many people?  Do you have someone who is creating huge unwieldy spreadsheets that many people need to keep up?  Do you a person called a programmer or Access guru that you live in fear will disappear?  All of these are indicators that you have a need.  Other indicators are frequent questions around the office like “Do you know if ……”, “What is the status of …..”, “Who knows where we are with ……”.  These are indicators that the right information is not available when needed. 

Squaretree has analysed many companies over the years and helped a good percentage of those.  Sometimes we decide with the client that Custom Application Development is not necessary for the circumstances, the systems and processes are likely to fit just fine in a standard program.  Many times though we are able to steer a company through a successful application development cycle that results in a reliable, manageable program that meets their needs and saves time and money through increases in productivity.

We hear that remark in various ways all the time.  From “I want a computer that just works” to “I want a network that just works” to “I want a mobile device that just works” and on and on.  It makes sense, all of these things are tools to get some other job done. It is the other job that is valuable.  The tool is only valuable because it enables that other job to be accomplished.  If the tool get’s in the way of the thing you are using it to do it is not helpful. 

Squaretree has turned that into an internal slogan.  We do not deliver servers, or server maintenance, or desktop support or router configuration or messaging expertise……we deliver systems that just work.  If we are not doing that directly then we are helping internal I.T. Staff to do that for their companies.  There are alot of benefits to thinking this way, not the least of which is engineers become focused on the solution no mater if it leads to the server, the routers and networking gear or the workstation and are equally proud to work on any of them since they are delivering the “just works” network.

So…the other day I said to my wife, “don’t bother me I’m trying to get done and my computer is fighting me all the way”.  And she said…..you guessed it…..”and you deliver what????”. 

So I had to start thinking about that.  One of the things that we all have to remember, like it or not, is the computer that “just works” is probably not the same computer with which you push the envelope of connectivity and usabilty constantly.  For instance the thing I was having trouble with was getting my second monitor to work.  Sounds easy.  But I have a high end laptop with a very specialized high resolution video card that delivers a very crisp high resolution display on my laptop.  It can easily attach to a high resolution second monitor.  But of course I don’t stop there I suspend the machine and connect it to another high resolution monitor that is different make, model and resolution than the first without letting it reboot or anything.   Oh and between times I’ve decided to use it without the second monitor at all, even though I had windows open on that second monitor.  And I expect it to keep up without a pause during all this perfectly while running Java graphic applications and Windows media player videos both embedded in web sites and stand alone……AND…..I have perhaps 5 web pages, 7 emails, outlook, calendar and 4 programs running all in different windows.  Oh and two web browser brands also.  You know it’s a wonder it keeps up over 99% of the time. 

We can deliver the network or the computer that just works. But much like other appliances you need to define exactly what it is you want it to Just Work on.  Then we can do it.  But if you want it to also be able to just work you also have to live with the fact that you can’t try to confuse it constantly.  If you want push the envelope you have to remember that it will likely take a bit more patience on occassion to make it Just Work.

Incidentally I got what I needed to do accomplished and only 5 minutes later than I was targeting which was hours and hours faster than if I had not had a computer at all.  So ultimately the tool really did “Just Work”

Continued from What is Managed Service really? Some history

From 2000 on I have been looking for ways to use the large systems management programs to make our engineering department and our network clients life better.  I kept trying to get our engineers to put a really large square peg in a pretty tiny round hole.  Products like Tivoli, HP Open View and Microsoft Systems Management Server were robust, full featured and mature products but designed and priced to meet the needs of multi-national corporations with thousands of P.C.s.  They could be scaled down to networks around a thousand and even to 500 to 700 PC networks but they broke down when working with multiple domains meaning multiple separate companies which are the networks we support. 

In 2005 I discovered several programs to address this problem that were finally at a level of maturity to be worth looking at.  The programs we looked at were N-Able, Level Platforms and ManageIT.  All had pretty good capabilities but N-Able added a business training aspect that would they claimed would take you from a reactive to a proactive mind set.  You might remember the program about a Law School where the opening was the professor saying he wasn’t going to teach them the law he was going to teach them to “think like lawyers”.  N-Able understood that it was not enough to simply add a  monitoring system.  The mindset of the engineering department had to change. 

I was tired of the fact that we could only react to problems after they showed up.  I was tired of EVERYTHING being an emergency.  I was tired of not being able to see in advance when a network was overloaded or when a disk drive was showing errors days before it actually went out and we had no reliable way to catch the problem.  I was tired of never being sure that a clients backup was actually going to restore since I had no control over the removal and storage of tapes.  In late 2005 we purchased the program and embarked on a path of change that was a far more costly and difficult path than I would have imagined.  During that time we replaced all our engineers and not just once.  We have had setbacks and successes, rousing accolades and a few more challenging moments.  But through it all I was absolutely resolute in the knowledge that the only way to change the way network support was done was to give the engineers the tools we had just discovered and then work hard to get them to see the vision of using the tools to look into the future and start making more things planned and less things reactions.

That was alot harder than I thought.  The imaturity of the business itself was fighting me, there was not a shared peer concensus on the best way to deal with networks.  Engineers were typically passionate about computers and learned by getting in and doing but lacked alot of discipline around the processes.  The best of them developed the discipline out of neccessity but they were all inventing thier own.  One of the most pervasive problems though was the desire to be a hero.  While it’s stressful and difficult to deal with the user who is frantically trying to get to a network resource it is immensely rewarding to fix the problem and literally have people call you superman or my hero.  It was hard to get some engineers to let that go. 

The managed systems software we have in place today allows us to work to two major goals.  1.  Every thing on your network that will result in a user symptom or risk will send an alert before or when it happens and we will know about it.  2.  Every alert we get is something we actually care about.

The more closely we can get to these two goals the more perfectly we can achieve a truely managed service and the more we can get away from everything is an emergency.

Next:  What a managed network looks like

The buzz word of the year is Managed Services and virtually everyone is on the bandwagon.  But what really is a managed services company?  How do you tell if your service provider is just using the word and perhaps “flat rating” your service but really isn’t Managing your network? 

Let me give you a little history of managed services first then attempt to answer that question.  I am writing specifically about companies who service small network systems.  Small networks are from 10 users to about 250 users and typically span from 1 to 6 offices.   The companies who have helped with these networks in the past have been hamstrung by the lack of tools to help with the problem.  The networks developed as simple systems, usually built by a self taught network amature turned pro.  Maintenance was break fix only, meaning when something broke, you called and they fixed it…hopefully.  As time went on the best of the support people developed companies with planned programs periodically coming on site to do a system review of log’s and user information looking for hints of issues before they became big problems. Squaretree developed an elaborate checklist to write down disk usage and processor usage, etc. and graph them over time in the hope of seeing issues.  The problem, of course, was that you only could see what you could see the day you were on site.  If something happened after you left you’d never know till the user called.  Also the only professional test of the backup system was on the visit, users on site needed to be very aware of the backup system.  This frequently resulted in days or more of missed backups.  Finally the system was prone to other human errors.  One of the errors was the dreaded “user list”.  Frequently the benefit of reviewing the server performance records was overcome by the urgency of a list of user desires that seemed more important work when the tech came to the office.  The tech, trying to be accommodating, would take care of the issues and not have time to get to the system work.  It was a constant battle to get customers to understand that they were only causing themselves problems down the road.

All this time the hardware and software vendors were adding new and better ways for the systems to signal problems as early as possible.  Simple Network Management Protocol had been developing since the early 90’s and was getting applied to PC’s and Windows Management Instrumentation was added to the operating system.  At first the systems that could watch these tools and turn all the data into usable information were complex to manage and geared to large networks.  Approximately 3 years ago systems started to mature that would allow companies like Squaretree that were managing many small domains to take advantage of the same features and benefits as the large companies.  The best of the systems are still very expensive, 10’s of thousands of dollars, but that cost can be mitigated over many clients.  It is this technology that started the Managed Services movement.  Companies differentiate based on the way they use the tools and the systems they wrap around them.

More in the next installment

I wish I was asked this more often before projects get in trouble.  There are many application development projects that go well in this world that is clear.  But as a company that get’s called regularly to “finish” a project that is almost done, we see our share of projects that are completely off track.  Every time we hear someone say “the project is pretty close to done but the programmer got another job so we are wanting you to just finish it up” we cringe.  Only once in 15 years has the program been anything but a disaster when we have taken it over.  It is stunning and amazing to me how many projects go over budget and fail to get even 50% of the intended results.   Worse by the time it is discovered that these failing projects are on the wrong track so much investment has been made it is nearly impossible to bring yourself to see the truth. 

So what are the warning signs of a problem project? 

1.  Analysis and specification documents either don’t exist or lack detail.

A specification for a program should be extremely detailed before you start writing any code.  There should be few if any statements of a general nature such as, “keep information about customers inquiries”.  A statment like this should immediately bring questions such as “what is a customer inquiry?   Does it come from the web? phone? email? fax?  Is any question at all from a customer considered an inquiry?  Do you need to know what time?  do you need to know who answered it?  do you need to know what answer was given and when?  how are you going to use these records?  there are likely to be thousands over time how will you look them up?  etc. etc. etc.”   If you do not have documentation that answers questions at this level of detail you have a high risk project

2.  The coding was started months ago and you get a question that is so basic you wonder how they could possibly not know that.  

By the time coding starts the team should know more about your business than you do or almost so.  While this is not a red flag it’s a warning to look deeper at what is going on and make sure the coding and project team really knows what they are trying to build

3.  The project is late and you are being asked to put more programmers on. 

The first request like this might not be the death nell but if the team size starts increasing and there isn’t a clear concise plan for deliverables being met then you can definitely say you have a problem.   If the original project was anticipated to take 1 main programmer and you have to add a programmer that was not planed you can anticipate 50% of that programmers time on additional overhead.  So if the project has 1000 hours left adding a programer risks making it a 1250 hour project.  A second is probably the same and more than that on a 1000 project run the risk of increasing the overhead time by more than they will help the project finish.  If you started with 3 programmers and suddenly you have 8 and your Project Manager doesn’t have clear and quick deliverables they can show you they are hitting that are testable then you have a HUGE yellow flag that is most certainly really red

4.  The project has been nearly complete, 80 or 90%, for months. 

You’re in trouble, the current team can not help you, stop!   

Application Development is a high risk endevour.  Done correctly it can give your company a competitive advantage that can have a very high reward for a very long time.  Done incorrectly and it can sink your company.  There are processes that lessen the risk including great specification writing and analysis, project management, risk management analysis and others.  Even these must be handled with judgement and skill.  Without them failure is very nearly certain.

Don’t get me wrong I’m a big culprit myself, but I’m working on it. 

A most interesting thing happened here the other day.  I asked for a review of a site in preparation for estimating a small amount of work.  In the enthusiasm to do good work quickly the recipient misread the email as a request to start.  She needed some help from a coworker and started the email with “Do you know about ……..”.  The response came back “First I’ve heard of it…..”  and then a series of statements about what had to be done.   Benign right, except she read the response to mean, “First let me tell you I’ve heard about this project” which rightly meant that anything he said after that could be interpreted as things he knew needed to be done.  What he meant was “That’s the first time I’ve heard of this project”.  In that case the statements following would naturally be taken as “if we go forward here are the things I think need to be done”.  Diametrically opposed meanings from exactly the same words. 

So it would be easy to look at this and say that the reader of the “First I’ve heard of it” sentence made the mistake by reading in the comma that wasn’t there as in, “First, I’ve heard of it”.  And you’d be right but……..how much can or do YOU rely on good writing skills in an email?  My experience is the typical email is full of acronyms, emoticons, missing punctuation and misspellings.  Perhaps the people you communicate with are better writers.  In my experience emails are considered fast communication and treated with disrespect when it comes to quality written communication.  And once you read a majority of emails with poor writing it is easy to begin to fall into sloppy reading habits as well.  If you can’t rely on the communication medium then why look at it carefully? 

How much productivity does this cost the nation?  I can tell you in our instance it lead to 22 emails back and forth with each of the people thinking the other was “lead”.  Fortunately it was a small issue and the direction paralleled the proper path enough that not much was lost.  There have been other cases where that has not been the result.

There are some who would say that definitions and punctuation and syntax are subjective.  I would say that to the extent that is true we degrade the very foundation of thier reason for existence.  The only reason a word has a definition is so when you say the word it invokes the same thought in my mind as it does in yours.  Same for punctuation and syntax.

In the worst case these small errors cause more back and forth than was neccessary and confuse simple tasks.  In the worst case a statement that was said with one meaning could be taken as completely the opposite by the reader and elicit strong negative emotions.  If the reader reacts it becomes hard to back down and bad feelings continue even if you point out the original intent of your statement.

You will do yourself and those you write a big service if you take a few moments to think about good writing technique in your emails.  You will loose less time with missed communications.   You could even avoid an arguement or two.