There seems to be a common misunderstanding for IT Support companies and IT Departments. When is a technical problem really a Business problem? Not understanding the answer to this question means that sometimes the IT Support team makes a decision for the Continued »

I recently worked as a panelist on a technical forum sponsored by the Institute of Management Consultants (IMC) here in the Pacific Northwest on “How the Cloud will Change your Business.” Before the panel started though, Eric Fry with One Accord gave a presentation about business red flags that cause business failures. I and the other panelists were intrigued by how we each had seen these business red flags affect the success or failure of technology initiatives as well. I thought these questions and comments by a non-technical consultant might be interesting to anyone developing modern network architecture.

I am often struck by how often business processes that make other departments successful, are not practiced in IT departments. I think most IT experts believe that their department is somehow different than other business departments. I think long before there were IT departments there were Engineering teams that felt the same way. The same frustrations management had with engineers building a Boeing plane are probably the same frustrations management has now with IT. Eric handed out a checklist, like a flight checklist, of problems that cause failure. As I read the list I could help think about my own Seattle IT consulting clients. Not just the owners and C-Level managers, but also about the mangers within the IT department or group themselves. As you read this list think about the C-level managers, but then also think about the same issues within the IT group you are a part of.

Lack of financial planning, Accountability and review (within the IT group)

Over-Dependence on specific individuals in the business (Alignment in IT around top technicians)

Poor sales and Marketing Strategy and or inconsistent advertising (Poor alignment of IT with marketing)

Failure to establish and/or communicate company goals (Often IT failure occurs because focus is on today’s problems not next year’s vision)

Inadequate capitalization, under funding or slow sales growth (How often do we play with new technology before we completely understand what we’ve got…)

Competition and lack of target Market Knowledge (How often is technology setup for the convenience of the technician rather than the productivity of each organization…)

Product orientation vs Market Needs orientation (How often to we recommend cool technology rather than technology that supports organizational goals…)

Owners concentrating on technical rather than strategic tasks ( How often is the focus on fixing a broken computer rather than understanding how that system supports the goals of the organization….)

I’ve always been amazed at how many errors are going on in any system. Yet many technicians keep running their systems as if errors are not occurring at all? Then when the system fails, the technician finally goes through the log files. I like the flight check list because technical problems are just like airline disasters. A plane doesn’t go down because of one major error. Statistically a plane goes down because of 7 small errors, occurring at just the same moment. These seven small errors by themselves are no big deal, but together overwhelm the system and crash the plane.

As we look at IT systems the same is true. Just because there is an error on the system doesn’t mean it will fail. Fail to address the technical error and the system fails. I work with my Seattle IT services clients in that layer between technology and business so I connected with Eric’s checklist. Not only do technical failures bring down a system but also the business decisions made within the IT department and by C-level managers outside the department also bring down the technical systems.

I find these types of failures occur between management and technology when they fail to communicate, commit and cooperate.

I spend a lot of time working with networks that are very large, very small and in-between. I recently visited a group of IT support experts discussing technology who support very small networks (1-10 users). I was a little shocked actually; I had thought the days Continued »

I think we must make technology look really easy. I hear this question from managers, owners and C-level executives almost every week. Well to be honest most C-level executives don’t ask this question. I think they get it more than we give them cred Continued »

Recently I’ve been researching a new laptop. While working on a project, I find myself with an extra client laptop. So I work using the laptop, and then return the laptop when I’m done. Recently I found myself handing back my laptop and realizing, that my newest personal laptop is loaded with XP and office 2007. So I’m asking the same question Continued »

About This Blog

Modern Network Architecture Investigates the diversity required when designing network infrastructure. We discuss the technologies and unexpected challenges. We may even laugh (or cry) thinking about the people and political situations that come up when designing modern network infrastructure.