As a Seattle IT Consultant I look for ways to save my clients some money, improve reliability and generally build value for the business. One of the fastest ways to quickly save the client some money is to perform a Service Level review of the printer and of the phone bills. One of my partners is a specialist in what they call, Managed Print Services, 180-Consulting specializes in this and actually very cool. Plus it’s something that’s never done in the IT Support world. My experts all work based on a portion of the savings they find. If no savings are found, they don’t charge for the Service Level Review.
I’ve been surprised to learn that most copier contracts are written to most benefit the printer provider. The price is designed to be very attractive on the front end. Then over the years the company grows. New copiers are brought in, old copiers are replaced. Somehow with each new contract, the cost on the backend seems most benefit the copier company. Most people wouldn’t even know. So my experts come in and save my client 10 – 30% (or more) on the copier contracts. When it comes to the phone company it’s just as bad. Very few businesses take the time month after month to review their phone bill. One of my experts tells me that a bill can be off 30% or more. The actual numbers are so high, most people don’t believe it. So I try to be conservative.
So when I meet someone and they say they don’t have budget for a new IT project I offer to do a free service level review on their software I suggest a service level review. “You never know… but maybe we can find some money that way”
The result is often $10,000 or more in savings for a small business and can be several hundred thousand for a large business. Suddenly cost isn’t a problem. The next question is
“What else can you do for me?”
This is always the start of a wonderful relationship. If you are an IT consulting company I would find the vendors in your area the do these types of reviews. If you can’t find them try here… I can help you find someone. If you are an IT manager, take a look at these bills… maybe you can find some unexpected income for your next project.
As a 3rd party independent, Seattle IT Consultant, I am sadly often pulled into a business problem after a catastrophic failure. This is the easiest point to have a Service Level Review. Unfortunately, after a catastrophic failure, this is also the most expensive time for a review. I always better understand the expression, Continued »
As a Seattle IT Consultant I am often called on to give advice or fix an IT problem. The first question I usually ask is do you have any documentation for your technology. You probably know what the answer to that question is. I recognized early in my career that IT experts don’t document. Continued »
Working with local Seattle IT Consulting companies, I’ve found that many companies don’t protect themselves with a strong customer onboarding process. This worked with systems were less complicated and one person could keep everything in their heads. When systems became more complicated it was impossible for even the strongest technician to get everything done over a weekend.
If you think about it, the onboarding process is just a checklist of things to do.
A) Identify objects to be migrated
B) Identify data to be migrated
C) Identify security settings that will need to be re-created
And so on until the last step before execution
D) Backup System
E) Backup system again
F) Execution of migration plan
There are several phases to an onboarding plan. When planning I usually start with a three phrase approach like Planning, Execution, Post execution follow-up. Since I’ve done lots of migrations, here are the phases that I use
- Assessment & Planning
- Review of systems
In the assessment and planning the IT Architect, identifies where the system is at. This is a review of the hardware, software, network objects and settings across the system. Planning is a step by timeline with all the steps to migrate each component on the system to it’s new environment. Because very few things work perfectly, we review the systems for a while to verify that all the settings are correct. This could take a few minutes or more likely days, weeks or months of monitoring and support.
Once the network is stable, the next step is to match the system to your company’s baseline. So if you were a cloud hosting architect, you know your SLA. Say it was 99.9% availability. Your job would be to optimize hardware, software and other objects to a baseline that matched the standard pre-requisites to maintain that 99.9% availability.
A good onboarding plan, in my opinion, has four stages, Assessment & Planning, Execution, Review and Optimization of systems. Under each phase are different tasks. About 20% will be unique from migration to migration. The other 80% will probably be the same from system to system. As the modern network architect, your job is to not only build, but maintain the integrity of the systems.
One of my Seattle IT consulting clients had a problem. After onboarding a new client, suddenly!… They were in the midst of an IT failure cascade. It started with all the workstations that were old and past their normal life span. Then servers would begin to fail. Continued »
I worked with the Microsoft team that was building the first Lync Multitenant reference architecture. This is an implementation of link that crosses state and continental boundaries. The four site itself was originally designed to support over 200,000 multi-tenanted users. Continued »
For a Seattle IT Consulting firm, It’s not hard to convince business owners that 365 is actually a good deal. $8 / month for Email / user is actually a great deal. A single Exchange implementation is going to cost about $5000 for a good business server. Continued »
I recently spoke for a local business newspaper, the Puget Sound Business Journal. Part of my marketing strategy is to discuss technology with local business groups and businesses. One of my presentations on the cloud has been made into a quick business video called The Monk Story. During this most recent presentation, I was discussing CRM strategy. One of the comments that kept coming up struck me as strange. More than one business owner mentioned that they had setup and installed 2, 3 or more separate CRM systems. Each one a failure only to be replaced by a new system that failed again. As a Seattle IT Consultant, I was surprised by this. Why is it that a business owner or management team would invest in technology and after technology? Especially considering that a CRM technology is pretty much the same from business to business. Then as I hear the comments by the members of the audience I began to realize that the problem didn’t seem to be the technology. Rather the problem was with the strategy. How often do we see a business use a new technology to do what they are already doing, just a little faster? Ford was attributed with saying,
“If I listened to my customers, they are just looking for a faster horse.”
Marketers tell us to listen to our customers, for what they are looking for, but when it comes to technology and especially new technologies is that really who we should be listening to. This may sound odd, but shouldn’t we actually be re-reading the vision and goals of the organization? Strategy is different from tactics. Tactics is about the day to day activities. Strategy is about the long term mapping of business goals. When we create tactics, they need to be in alignment with the strategy. Without this alignment, tactics can never change. Eventually the business fails because the competition has replace their tactics with more effective tactics. The strongest business though, replaces their strategy before replacing or thinking about their tactics.
Too often a business owner hears about a new technology and implements it. I’ve mentioned sometimes that in the old days we got computers into the workplace by pointing out that a typist can correct mistakes without retyping the entire letter. This is kind of like the faster horse idea. We are taking less and less time to create a letter or document with fewer and fewer mistakes. This is cool, but really not the value of information technology. For example: 100 years ago, we taught sales people that finding new customers was about knocking on every door in town. It’s became a numbers game. We noticed that 80% of business came from 20% of sales people. We noticed again that 80% of business came from less than 20% of customers. We also found that 80% of the work was focused on customers that bought less than 20% of the income for the organization. Today we only have to identify the 20% and we can increase income by 4 times more than if we focused on the entire customer base. Yet how many business owners, sales managers are still focusing most of their time on the 80% who buy so little of the company’s products.
These businesses in my presentation, who are replacing their CRM systems over and over again, are stuck. Not by the technology, but because their technical strategy is not in alignment with the business strategy of the organization. I blame this on the business leaders who delegate their strategic leadership role in the organization to the tactical understanding and experience of their technical staff. To move up in the organization, it’s important for the modern network architect, to stop being a technical expert, but become a business consultant who specializes in technology.
Walking to a new client site as a Seattle IT Consultant, it would be easy to blame the last guy for all the mistakes. I have a 6 month window to repair the failures. I also know that I can sell replace equipment that will last at least another 18 months before those systems fail. So it’s easy to take potshots for a year or so, rather than identify the real problem. I know I’ve said this before, but I believe all technical failures are actually business failures in disguise. The reason we as IT experts don’t realize this is because we are IT experts not business experts.
In my blog article “The biggest root cause for IT failure…” I gave an example of how putting a server on a 5 year depreciation cycle could have saved a business from a catastrophic server failure. Not just the failure, but also the lost productivity while the workers were fixing the problem. We, as technicians, are all consciously aware that down time, means lost worker productivity. The business owner realizes that lost productivity means lost profitability. Since we don’t think in terms of profits, we often don’t think about the consequences of our behavior on the bottom line. Since technology seems like magic to many our managers (and sometimes our technical peers) perhaps we should understand the consequences a little better.
Statistically 70% of all IT failures are due to human error. 30% are due to hardware failure. Usually we see the hardware failures before we put the systems into production. Later on we see hardware failures again after the server has passed its life design specifications. If this true, then for the first 5 years in production, the majority of failures are caused by human error. Should we be condemning the IT department for these human failures?
If, as I say, all technical failures are actually business failures in disguise, then I would have to say no. Human error is part of the risk that managers are trained to account for in all business systems. Ultimately and IT system, IT is actually a business system supporting a business process. If we look at other departments we see that there are systems for reducing or eliminating the effect of human error.
For example: In accounting the CPA for the firm is held accountable by the Controller for the organization. Management is held accountable by the board of directors and the stockholders. Each business system includes a check and balance to keep everyone honest. In most business departments if there is a failure, it’s usually because a business check was not being maintained. In the IT department though, these types of business checks are not always in place.
As an example: When I started RAID arrays were monitored by the technician assigned to the server. One of the technician’s job was to check the green lights on the servers. If there was a red light, the drive had failed and needed to be replaced. Yet year after year of seeing green lights, a technician might miss a red light. Not just miss the light, but miss the light month after month. Until finally the second drive in the array also failed. Then the technician was often fired. While this was big mistake, was it appropriate business process?
On a ship during a war, there was always more than one sailor searching the horizon for submarines. Why? Because one tired sailor could make a mistake. We also can’t depend on radar or Sonar to always be right. Sometimes bleeding edge technology can outfox cutting edge technology leaving the ship open to surprise attacks. Our fired technician may have functioned just fine up until that moment. In know I’ve missed a red light periodically. Thank goodness I had more than one set of eyes looking with me. As a result we always caught the failed drive before it became a problem. Perhaps the real problem wasn’t that the technician missed the red light, but that there weren’t many eyes reviewing the lights.
Today we have automated systems doing much of the review, but is it wise to depend exclusively on those systems? We know that systems report only what they are programed to report. So as part of our business process perhaps an additional audit of the systems might identify additional risk. It’s when we assume that weakest link will never fail, eventually something will fail. Whether that system is a technical or a manual process there will be failures. Ultimately it’s not the technical systems fault any more than it is the technician’s fault. There is a business process that should be catch failure before the system actually falls over. This is why I say… all technical failures are actually business failures in disguise.
As a Seattle IT Consultant, my role is not to approach technical failures as technical failures. I’ve noticed that technical experts tend to approach all problems as technical problems. As a result if something fails, the technician takes on more responsibility than they should. Management’s role is to take responsibility of the resource management of the organization. What I keep finding as I consult, is that many IT professionals take on the role of owner, rather than technician. The result is a technical failure that could have been resolved by the management long before the failure actually happened.
Here’s an example of what I’m talking about.
- A server fails.
- The network goes down for ½ a day
- Lost workplace productivity is over $200,000
Whose fault is this?
The first reaction of course is that the problem is with the IT department. The IT department’s job is to keep the systems running. After all, servers don’t fail, do they?
A review of the server reveals that the server was 8 years old. The server was also the first server built for the company. The server was the natural repository for all company files because everyone knew where the data was. So now whose fault was it? Does the fault still belong to the IT Department? After all shouldn’t the IT department have warned management that a failure could have occurred?
These are the thoughts going through the minds of most IT technicians and many IT managers. While it could be argued that the IT department should have caught this problem, this argument is misleading. It assumes that all departments are responsible for tracking their own capital assets. But they aren’t so why is the IT department different?
You may be asking, “What are you talking about? That sounds like an accounting thing, not an IT thing!” If you asked this question… you’d be exactly right. This is also my point. There are already non-technical business processes that should be in place to catch the failed server before it reached 8 years in age. Very few accountants would assume a company truck would last 8 years. A building that is 8 years old has met ¼ of its expected lifespan. All assets expected to last over 1 year are capital assets and should be on a depreciation life cycle. The value of the company is based on these capital assets. As assets depreciate, the value of the organization also depreciates. A depreciation life accounts for this loss of business value.
What’s a depreciation life cycle?
Depreciation refers to the decrease in value of an asset over time. Since every accountant knows that every asset depreciates, the account puts the asset on a depreciation life cycle. They do it with trucks, buildings, assembly lines and should be doing it with servers and desktops. Yet most business leaders never do. As a result the server runs year after year until if finally fails. Servers are designed to last 5 years. So after 5 years the servers should be replaced. Part of the accounting role in the business is to put aside money for replacement of all capital assets including servers.
Therefore if the owner, the CPA and controller had put the server on a 5 year depreciation life cycle, the server would never have failed. Because that server would have been replaced three years before it failed. That’s the way it’s supposed to work, but most technicians know nothing about accounting or depreciation life cycles. They quickly take on the role saying it was our fault. The accounting department and even the CEO is willing to let the IT department take ownership of their issues. I don’t actually think that’s fair.
So when I consult, I ask several questions. One of the first is, are your servers on an accounting depreciation life cycle. This is often the first time the business owner and the CPA have ever realized that servers don’t last forever. We can laugh at management, but wasn’t it our responsibility to let them know this? Ok… perhaps not, but we could have. That’s what I do and as a result, I never have to take ownership of the failures that occur when server gets too old. I just say… see… I told you.