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
• Execution
• Review of systems
• Optimization

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.  Eventually even routers and other systems would begin failing.  No client likes to pay for brand new equipment.  So of course, insisted that the reason for the failure was my client’s fault.  So my client was replacing hardware at the end of life.  This of course led to a discussion of customer onboarding.

As technology experts we just think of onboarding as a technical process.  We are migrating data, software, settings, network objects and hardware from one environment to another.  We often want to do this quickly and with as minimal downtime as possible for the users and customers of our clients.  Most technicians are juggling a lot so expecting them to also juggle the business side is a little unrealistic.

So as technicians we create an onboarding path for our new clients.  Now here’s the rule I use for onboarding.  If my client is an Seattle IT Support company, I make the onboarding process very long.  If I’m my client is a customer, I may be tempted to encourage a very quick onboarding process.  The quicker the onboarding process, the more liability is placed on the shoulders of the IT Support Company.  So my goal with my Seattle IT Services and IT Support clients is to slow down the process.

The IT Services Company should have a big advantage when it comes to keeping down costs for IT Support.  After all they have better architects designing the systems, better vision about the future of technology, system administrators with more experience and stronger technicians than their clients could afford.  Put that together with a solid NOC and we should be seeing a bullet proof operation for the IT Services Company. The risk for the IT Services Company is bringing unknown systems into their environment.  Each change means the possibility for failure.  This is why an onboarding process for customers is so important to the IT Support and Seattle Cloud Architecture company.  The contract will read something like,

We support systems within our base configuration.  All systems outside this base configuration will not be supported by the SLA.  As the client systems fail or are replaced, we will maintain all systems installed by us at the best possible SLA possible for the customer.  All system repairs for non-compliant configurations will be priced at a discounted fix rate price.

So instead of a weekend onboard, we contract the onboarding for 6, 12 or even 18 months out.  During that time the onboarding teams job is to bring all systems into compliance with the SLA requirements for the new company. When expressed this way, it makes the migration to the cloud seem fair.  Nobody expects the cloud company to support all the systems, as if they were already SLA compliant, before the systems are ready.  The IT support company is no protected from past mistakes and can focus resources on slowly building out the network.  Onboarding actually becomes a benefit for that the sales department can use to sell the onboarding process.

Most IT support companies have problems in the first 6 months of the migration onto our site.  This is often because they are inheriting the problems from your last IT Support vendor. 

So instead what we do is onboard you over a 6 months.  During that time will fix or replace all the problems we find that migrated from your old system.  Once the onboarding process is complete and we certify your systems as compliant with our SLA, any failures will be fully covered.

So a well designed onboarding plan sets the new customer with the right future expectations.

Change is always interesting.  With the way technology is changing so quickly, I have begun to feel a little dinosaur-ish.  Meaning that I get stuck in the old way of doing things and the idea of changing is becoming more and more daunting.  I have been a Seattle IT Consultant for the last 20+ years.  I’ve worked with the Apple IIe and other early computer systems.  I started my career, switching from being a landscaper, in the DOS 3.0 days.  So I guess it’s understandable that re-inventing myself seems more difficult today than it did 5 or 10 years ago.  Yet I look around at our industry and I see that other IT experts have an even more difficult time changing.

So where are we at today in computers?  I am doing a presentation in Seattle on CRM where talk about one of the dilemmas of technology.  That’s where we embrace a new technology, but we try to do what we’ve always done.  In my presentation I quote Ford, who is supposed to have said,

“If I listened to my customers, they simply want a faster horse.”

Yet we see how the automobile changed everything.  In the early days of the car, manufactures tried to make the automobile look just like a horse carriage.  Today’s automobile has four wheels and seats for people to sit in, but that’s where the similarity ends.  Cars today would be unrecognizable to the early drivers.  More importantly even in the 1950’s the last holdouts were still people grudgingly accepting the combustion engine.   When I started 20 years ago we were trying to convince business owners to accept computers because typists didn’t have to start over when they made a mistake.  Early business owners would accept a “Faster Typewriter” before they would accept the idea of a computer.  Sounds like a similar dilemma for Ford, his customers wanted a faster horse.  In the 90’s business owners wanted a faster typewriter.   This is the dilemma of new technology, as it changes we thought what we really wanted was a faster horse.

You’d think as technology experts always promoting change, we’d get this?  Yet when I look around, I see technology people who are having just as much problem changing.  They are happy with where they are at and what they already know.  I’ve seen it every time the technology changes.  Each IT department wants to think about more servers, switches, routers and computers and think about them in the same way.  There used to always be a division between the data guys and the voice guys (Now with voice over IP and Unified communications that division of labor is changing).  As things changed we see managed services models replacing break/fix services (it’s cool technology, but it puts the break/fix troubleshooters out of business).  I can list technology after technology that is more efficient and being replaced in the same way.  So it’s surprising when I hear IT Support vendors who aren’t embracing the cloud.  They seem to want bigger, faster and easier to manage servers and more of them.  At the same time, they ignore the reality the reality that technology is changing.

So where are we at?  At the beginning of the path?  The end of the path or maybe in the middle?  I personally feel we are just reaching the point Henry Ford reached when he setup his factory with the assembly line.  Right now we are used to hand crafted technology where business technology is built from the ground up.  Yet when Ford re-perfected the automobile manufacturing hand crafted automobile became an oddity almost overnight.  Businesses that ignored the trend went out of business.

As technology experts we can’t get lazy or be afraid of change.  The modern data assembly lines like the cloud, can only be ignored until your company or client is out of business.  Then where will you be?  If you aren’t migrating your systems into the cloud, you may just be you holding your employers or your clients back.  The cloud may only be a marketing term, but it is the next step.  If we try to convince our employers what they really need is a “Faster Horse” aren’t we just condemning our clients to the world of the dinosaurs?

Most IT experts are thinking tactically.  Our job as is to think about how to do things.  How am I going to keep systems up and running?  How am I going to fix something that failed?  How am I going to do what I’m doing more efficiently?  We look to the leaders in the organization for why?  When I started, I only wanted to know what it was that you wanted me to do.  I never asked why?  When I became a Seattle IT Consulting expert I found that asking the question “Why”, was a much more important question.  I’ve found that IT professionals with the most experience answer every question with the comment, “It Depends.”  What they are really saying is why.

Asking “Why?” is the first step in building business value. 

If we want to increase the value of a business, it’s first important to understand in what ways the IT department or an IT Services vendor can improve the value of the business.  There are at least 5 ways to value a business.  To complicate this more each industry has a different valuation metrics.  For example a Dry cleaning company could be valued by 70% of annual sales plus the value of its inventory.  For a law firm the value would be between 40 and 100% of annual revenues.  The book value of a business is Tangible assets minus Liabilities. 

No matter how a business is valued, the ability to create cash flow is essential.  Cash flow is a basic equation of income minus expenses.  With cash flow, assets can be increased, liabilities can be reduced.  A movement in either of these directions increases the value of the business.  Technologies strength in increasing business value is to reduce the cost of doing business.  Technology has always reduced the cost of doing business.  Horse drawn wagons carried more freight than a man could carry.  Horse drawn wagons were the technology that reduced the cost to deliver goods from one location to another.  Train, trucks, automobiles and even airplanes reduce the cost even further.  As an example: A freight company depending on human baggage carriers will never compete in today’s market. 

This is the value technology brings to business.  Early adoption into technology gives competitors an edge.  Now business can save time, costs and even improve the quality of their products or services competitors can’t achieve.  Cash flow and profit is determined by income.  Income levels are determined by the expense required to create that income.  Utilizing technology to reduce expenses, income is automatically increased.  As income is increased, the value of the business is increased.

Cloud technologies becomes a latest method of reducing expenses for small and medium size businesses.  This is done in multiple ways including: Reducing Capital expenses, increase workplace productivity by decreasing IT downtime and negating the effects of depreciation of long term technology assets including servers and supporting technologies.  Simply by moving into the cloud, IT downtime can be improved from an industry average of 90-95% to less than 1% downtime.  Increasing workplace productivity alone by 5% can easily equate to an increase in business value of 30%

I work as a Seattle IT Consultant, sometimes as a part time CIO or technology architect for my clients. One of my potential clients was struggling with the concept of strategic business strategy and asked,
“Give me examples of ‘business technology strategy. Define this for me. Tell me exactly what it is you put together for clients.”

It’s a very good question, hard to explain, but at an important question. Most people are either tactical thinkers or strategic thinkers, with the majority thinking tactically. So the simplest way to start is to compare IT with Accounting. I’ve used this Accounting Analogy before, but bear with me…, There are four main accounting roles that correspond to four main IT Roles:

• CFO CIO
• CPA, Controller System Administrator, System Architect
• Book Keeper Technicians

CFO’s & CIO’s think strategically
CPA’s & System Administrators, manage the day to day business accounting systems
The Controller and System Architects design and verify that the day to day system processes meet accounting or IT standards
Book keepers / Technicians track the day to day record keeping under the direction of the CPA.
The accounting system is designed so there is a natural confrontation between the CPA and the Controller. In the same way the System Admin and the Controller conflict in healthy IT Departments. We also see this between ITIL roles for Incident and Problem Management.

The C-level executive in both departments will go to members of each role for specific advice, but would recognize the context of that advice and the training and understanding of the giver. He/she would also understand that they are strategic roles who are focused on the day to day activities. They are not thinking about the long term strategy of the organization, nor are do each of these roles have a big picture of the entire organization.

The problem I find though is that in SMB organizations and this model is not defined at all. Someone who is a technician is expected to play every role, Including the roles that should be confronting one another like system administrator and architect. When I see network failures, I’ve noticed that these roles are not well defined. The system administrator is also playing the system architect role. In accounting this is a big red flag when the CPA and the Controller are the same person. Similarly In IT departments red flags should also go off for the CIO and the CEO of the organization.

What is happening with most IT vendors and in most IT departments is that a technician (an equivalent role to a book keeper) is doing the system administration, designing the network and doing the 5 year planning for the organization. In other words the technician and even a good system administrator are not qualified to function in a 5 year planning role. Nor is there a role that is in conflict with the system administrator making sure the system administrator is following best practices. Finally most of these vendors are assuming that a network is a network, so as long as they build it and control it, the business should be fine.

Systems have technical failures, but fix for future problems isn’t a technical solution. Rather the solutions should be to fix the business organization in the IT group.

Technology projects without “CapEx” spending.

I remember early in my career sharing a great technology project with my manager.  The manager admitted that the project would be beneficial to the company, but he didn’t have the budget for it.  I was surprised because we had just hired three new employees and had plans to hire two more Seattle IT Consulting companies.  My project, I explained, would cost much less than, just wait a month to hire those two consultants.  The next phrase would dog my modern network architecture career.

“You don’t understand, James those expenses come from a different budget.  Your project would come from the CapEx (Capital Expenditures) budget.  Those employees and consultants come from the operations budget.  I have lots of money in my operations budget, but my CapEx budget is very small.”

Then he said,

“Too bad you couldn’t qualify your project under a the operations budget, then I could fund it.”

Thus began my first step away from technology understanding and to understanding the budgets that determined whether I could play with my shiny new technologies.  Hence my career struggle with the Capital expenditure budget.

Servers, because they depreciate over a period longer than 12 months, are expenses assigned to budgets that pay for capital expenditures.  Any server purchased for a technology project, came out of the CapEx budget because servers depreciate over a 3 – 5 year period.  As a consultant if I wanted to keep my contract moving past the projected end date, I needed to propose new projects.  So If I wanted to keep working I needed to propose projects with servers that were already purchased.

Well that is until the cloud.  With the cloud servers don’t cost anything.  At least from the context of the CapEx buget.  The cloud service provider has already paid for the server.  So when buying a cloud service there is no capital expenditure.  Instead the expenditure comes from the operations budget.  This is the same budget where those employees and consultants were being budgeted.  Now anyone can fund a new IT project through the operations budget.  So now my servers are basically free.

Now I can propose project after project to my clients and the operations budget pays for everything.   If you are an Seattle IT consultant, Boston IT consultant or a consultant from anywhere and need to find a way to extent your project, propose a cloud project.  Now your client manager will say,

“This is great! I can fund this from the operations budget.  Now I just need a business reason for running this project.”  The cloud is the biggest boon for the Seattle IT Services provider (or if you live someplace else just insert your own area) because operational budgets are much deeper than CapEx.  Now for the business this is great also.  The reason is that CapEx funding can be re-directed from IT (a direct expense against gross income) and used to fund projects that directly support the core business systems that directly improve profitability.

Tip: want to benefit your organization?  When your server is old, don’t replace the server with CapExp budget money.  Instead put that server in the cloud and use operational money.  Then use the CapExp savings to benefit the profitability of the company.  You’ll be a hero in the accounting and operations groups.

Plus you’ll be building political favors when you want to invest in a really shiny new technology.  I’m curious if others are utilizing the value of cloud network architecture in the same way that I do in my IT Consulting practice.

Want to learn more about Cloud Architecture?  If you are in Seattle in September, visit my presentation.

Collaboration is becoming more and more of a buzz word.  Marketers of the cloud and cloud technologies are describing collaboration as a major feature for moving into the cloud.  Yet from a technical standpoint what is collaboration?  What is the benefit of technical collaboration?  What are the tools that will need to be integrated into a virtual architecture that will benefit collaboration in business organizations?  As a technical architect I discuss these topics with businesses, management teams and owners.  Understanding my IT consulting client’s collaboration needs means I, as an IT consultant, need to understand what collaboration is. 

Collaboration or Cooperation we often use these words interchangeably.  In his book, CREATING A COLLABORATIVE ENTERPRISE, Robert Nitschke breaks down the collaboration with three quantifiable terms.  There is no collaboration without 

• Cooperation
• Communication
• Commitment 

By breaking down collaboration in this way we can better define a technical system that enables cooperation within at team, within a company or between organizations.  Collaborative software systems are a very broad topic.  Quantifying a system as a good or bad collaboration system is difficult because the topic is so broad.  Utilizing Robert’s breakdown of collaboration allows us to define what makes up a good collaboration system. 

Cooperation – The first network that allowed users to share files also allowed cooperation.  One of the biggest problems for manufacturing was version control.  With 10 designers working on a problem, understanding what version was the correct version has traditionally been a difficult problem.  It’s not unusual for the wrong version of a diagram to be sent to manufacturing, and those manufactured and sold to the public.  Having a central location where blue prints and diagrams could be stored let everyone track the latest versions.  Centralized data storage and version control was an early collaboration system. 

Communication – With better version control more engineers could be involved in the design process.  As the number of engineers grows on a project, the more difficult it becomes to communicate across the team.  Project management software, email, SharePoint and many others became systems for communicating information within a team, across departments and even between organizations. 

Commitment – The final piece of the puzzle is commitment.  There needs to be a way to track collaboration partners.  Accounting needs to understand the hours worked on a project.  Management needs to understand the progress of the project as well as the resource allocation.  Accounting and Project management software allows leaders to quantify the commitments required to complete a project by each member.  This allows each team to understand the commitment they are making to the collaboration group. 

A collaboration system is actually not a single system but a compilation of systems that fit within an organizational culture.  The modern network architect needs to understand these systems and integrate them in a way that benefits the business as a whole and can be managed by the technology partners inside and outside the organization.  Because the cloud is external to the organization, collaboration is possible because the systems are accessed in the same way by all team members.  The cloud system doesn’t care whether the user is from another department or another organization.  The technical architect designs the security in keeping with the unique aspects of each collaboration opportunity. 

Owning a Seattle IT Consulting company specializing in Cloud networking Architecture and collaborating with cloud technologies partner I spend a lot of time collaborating.  Collaboration is becoming a much more important part of what my clients are looking for as they are exploring new technical opportunities.  I’m curious how you the reader are defining collaboration to your clients and management teams.