I’ve been using Windows 8 for about 5 months now. Sometimes I love it, other times I’m a little lost trying to navigate the system. I notice that many of my clients are not migrating onto the system yet. I wonder how others are finding the system?
In the world of IT management styles seem to be more and more confusing. As a Consultant, I’ve worked with teams from all over the world. The hours were long, sometimes sleepless, but very very satisfying. Then things began to change. As networks became more complex, more and more experts were added to the teams, some who came from Continued »
This is a question I began to ask myself. As a consultant I am often asked to collaborate on projects with other consultants. It’s a great experience when to experts in two separate companies can fill in the gaps by combining combine experience. Then complete a project that the two consultants couldn’t have Continued »
When I started in IT, Novell was the big player owning 70% of the networking industry. WordPerfect owned word processing and had the best print drivers on the market. Lotus 123 owned spreadsheets and I could go on. So now 20+ years later I am a Seattle IT Consultant with certifications in Novell, Windows and experienced as a project manager and in ITIL. The world of technology has changed dramatically, and then changed dramatically again and again. With the cloud, UC technologies and big data we can expect to see the whole industry turned upside down two or three more times in the near future. So the question is… with so much change occurring regularly how do we plan what our network will look like in 10, 5 or even 2 years from now?
My personal feeling is that the weakness in IT is that the IT department is actually a tactical not a strategic arm of the business organization. Sure we hear the term web strategy or server strategy, but in actuality these are just marketing terms. Tactics focus on the day to day execution. Strategy is not focused on the day to day. Strategy is focused on the long term picture and alignment with a long term vision. The IT department doesn’t focus on the long term. Instead technology groups are focused on getting things fixed, managed or implemented as quickly as possible.
It could be argued that there are many strategic tools that the IT department uses for technology planning. Some of these tools include;
Data repositories that include system life cycles, information knowledgebase, and historical records for tracking projected vs. actual metrics and more
Capacity Mapping tools that visually graph business capacity vs. actual technical capacity
Gap Analysis tools that identify the so call “stretching seams” in the present capacity as business grows
Unfortunately these and other tools are very static when looking at the long term future of data systems. We know that in the future technology will change and tools will change. So these tools can really tell us about what’s going on now.
True strategic planning thinks into the future rather than assuming that today’s problems will also be tomorrow’s problems. Who should be making strategic plans for the technology department? If the IT is truly a tactical component of the business, should IT be doing the strategic planning for the business? As strange as this sounds the answer is no. Now many IT professionals would argue, my CEO doesn’t even read his own email. How can this person possibly make a strategic technical plan. I think this is a good question. Yet lets look at the other departments. Though the CEO is not an expert in Accounting, the board makes strategic decisions for the Accounting department. The same is true for every department, people who know nothing about HR, Law, marketing, sales make strategic decisions for each of those departments. Why should it be different for the IT department?
Throughout my own history in IT, when the IT department has made strategic decisions about technology the department gets in troubles. Because the department is in trouble, the business quickly follows. When IT is truly successful it’s because the top level strategic thinkers in the management team have designed the strategic planning for the IT department. Working as a technology consultant, I thought my role was to represent the IT department in the board room. What I find is that I am actually representing the strategic vision and leadership of the management teams to the IT department. When the IT department follows the strategic planning of the management team everyone, including IT, is successful.
Lately I’ve found myself in a new role. Most companies IT departments are functioning, but nobody really understands how well those departments are functioning. When I’m called in as an IT expert its usually to verify the state of the IT department. Most owners are clueless about whether the department is functioning well or not. To be honest most IT departments are pretty clueless as well. Not about what they think their job is. But about how their job should have changed as the business grew.
The IT role changes in many ways. First and most obvious as the technology changes, the role of technology expert is to keep re-learning the technology each time it changes. Many technology experts are experts in multiple technologies. So the learning curve is constant as we learn new technologies and develop new skills in those technologies. Then it starts all over again as a new change or a new technology is rolled out into the work place. This learning by itself is enough to keep any technician on their toes.
The role of the technology expert changes in other ways besides technology. Another important way is with the growth of the business. For example: Change control is actually pretty easy when there is just one expert managing a system. Even with 2 experts, it’s not difficult if both experts are constantly communicating. Now imagine 10 experts or 20 experts. The casual methods of change control start breaking down. Non documented changes are “fixed” by other experts causing the system to break down over and over again. Change control becomes a governance role in the IT department to avoid problems where one technician is stepping in and breaking the fix of another technician.
My role has changed as well, now I see myself as a governance role. I don’t walk in and fix technical problems. Instead I walk in and fix the business processes. Before I can fix the process, I need to understand what’s going on. The process before fixing something is called Due Diligence. In this role you don’t fix technical problems any longer. This is the common thing about a governance role, it’s not about fixing things, it’s about fixing process.
Due Diligence is about figuring out where everything is at right now. The first question I always ask is, “Where’s your documentation?”
You can imagine what the response is to that. There’s more documentation today than there was when I was first managing networks. The problem is that even with the most advanced networks, nobody really knows how to build a knowledge base. Second even fewer technical experts understand how to write technical documentation. So the first question is often the first problem. My job becomes documenting, at least at a high level, the technical environment.
I then begin reviewing the system logs. I want to identify risk for the owner. If there’s no documentation, there is also probably no analysis of the network itself. The first step then is to document the risk status of the network and report those to the management teams. A
The next step is to begin identifying the roles in the IT department. I’m looking for governance roles. The reasons network fail is because there are ineffective governance roles. If for example the IT department head is also managing the servers, running incident tickets, designing the network and doing root cause analysis we have a problem. All governance roles must be held by separate people from the roles they are governing. The system architect should be verifying the function of the systems. The root cause analysis must be done by someone other than the Incident technician. These are all red flags when analyzing the network.
Due Diligence is the process of gathering the data that the governance role will use to analyze the network. I’ve never been called into a network that had appropriate governance roles. These networks manage themselves well. I have been called into companies that have grown past the capacity of the present IT staff. Through due diligence, my collaboration partners and I, have found it’s possible to identify risks and missed opportunities. Then the governance role can analyze and create new business processes for the IT department to follow. The result is a strong and more efficient team.
In planning a project, one must look at scope, resources and time. Seattle IT consulting experts in my area often focus on the technical execution of a plan. The other aspects of the project are ignored. I think this means that we are undercutting ourselves as technical consultants. So I created my Technical Collaboration Outline as a help to try to sort out what I was missing in my ball of string
What I found for myself was that I wasn’t planning my projects well enough. It turns out the technical execution is actually a very small part of the project. As the project becomes larger and more complex, the non-technical aspects of the project become more and more important to consider. Planning a project for me is like setting up dominoes. When you push the first domino each of the following dominoes falls next. So with the energy to push that first domino dozens, hundreds or even thousands of dominos will be affected.
Taking the domino analogy one step further, in a project no all dominos are the same color. Some are black, some are blue, some are white and they all need to be ordered in the right way. It turns out that planning the project is much more important than the execution itself.
We’ve all been on projects where suddenly the dominos stopped, even though here are dominos still standing. What happened? On domino in thousands was ignored so it was just a little to far away when it fell. This meant it missed hitting the next domino. If you’ve been on a project like this, trying to start the next domino in line becomes a real problem. Now the project team is putting out fires. Fires that probably never should have started.
Sun Zhu taught his leaders to plan everything in their headquarters not on the battle field. What I find with most projects is that there are some fires that couldn’t have been anticipated, but 90% of the time fires on the project are a result of poor planning. To avoid fires I add what I call governance roles into my planning. An example of a governance role can be seen all over business. The controller is a governance role for the CPA. The Human resources department is a governance role for the employees. The board of directors is a governance role for the CEO. When IT departments and technical projects fail, I’ve found it’s because we don’t plan any type of governance role into the project. Among my partners, I always try to assign a business governance role and a technical governance role. The business governance keeps the project on track and makes sure no roles are getting side tracked.
The technical governance role allows me to verify that my technical experts are being honest with me. We’ve all seen technical experts who use their technical expertise as a way to consolidate power. Adding technical governance negates that power. I use technical governance to hold my technical experts accountable on a project. I put the governance piece in form the beginning so everyone is aware that that can’t shade the truth in any way
In discussing technical teams, I run into lots of technical experts. As a Seattle IT Consultant I try to tie these experts into a cohesive team. The challenge is that in IT technical experts are very independent people and aren’t used to depending on other people. Often they have functioned in teams before and have seen others make mistakes and fail. Most exerts I work with will jump in and contribute to the team outside the original scope of what their position. One thing IT experts love to do is solve problems. Sometimes on a project this causes problems. Is one member contributing to much? Where does the money come from to pay for the extra work a collaborator performed? Shouldn’t it come from the under-perming member? How do you quantify that? I’ve come up with a tactic for helping me circumvent problems like this. In this posting, I’m calling it my technical collaboration outline.
In this outline I break down the roles within the project. For example a simple set of roles might include: Finding the project, Selling the project, Business tasks (billing, vendor payments, and non-technical activities), business governance, technical governance, Technical execution and account management. You and your collaboration partners would decide a different set of roles… Then we all agree to a set of percentages for each role. (i.e. what percentage of the project is finding customer.) We end up with a table that looks similar to this…
- 10% Finding
- 10% Selling
- 10% business task
- 10% business governance
- 40% technical governance
- 10% account management
Then each partner takes on one or more roles within the project. Each partner is paid a percentage of the project based on the percentages. People are then assigned to each role. The governance piece is about making sure that no person slacks off or steps outside their own role without getting paid. The result is a much more satisfying project for everyone. Most importantly each partner is paid a known amount based on their contribution to the project. It’s actually quite slick.
As a Seattle IT consultant I am really just a self-employed expert. I have teams of experts that I work with, though most of them are not employees. I call these teams my collaboration partners. My collaboration partners are some pretty smart people in their own technical area. Unfortunately there is more to being a consultant than just technical expertise. I’ve noticed that the good thing about technical experts is their courage in jumping into a new technology and winging it. This works well in new technology…, but not so well in business and team building. So I’ve found there is a trick to building a teams of independent experts into a cohesive team. I want to share some thoughts I consider when building a strong cohesive team of experts.
Time – time is the first thing to remember. It takes time to build a team. With all the contractors and IT consultants out there, technical experts are used to working with people they’ve never met before. These experts don’t really think about just how complicated this is. What most of us don’t realize is that the better the project results, there’s probably a really good project manager in the background tracking all the team members. When building a team of independent technical experts, a project manager that understands each member of the team is not always possible to bring into the project. So when putting together a team of experts, you have to play that role. When you play that role it takes time to get to know your partners. I have one partner I’ve been working with for a year. I’ve known him for 10 years. I think though that we are finally beginning to trust each other enough… and that took time.
Roles – A project is like a group of strings rolled up into a single ball. At first, just looking at the ball it seems like there is only one string. But untangle that string and you find that there are about 7 strings rolled up together. If you look at each string, you notice that there are even more strings rolled together to form the string. The more you analyze the ball, the more you realize that this one ball of string is actually a complex ball of strings. Each string is a different role within the project. It’s important to understand each person’s role within the project. Then as a project leader you will need to setup governance on those roles to verify that each person is performing their role. Just as importantly, there aren’t members of your team performing the same role without realizing it.
It comes back to time and trust. To make that ball of string work, you need collaboration members who trust you when you tell them… You are playing the wrong role. You need that trust also so that when you focus on one members work, they see it as a benefit, not as criticism of their work. In addition, you want them to know that in addition to trusting you on the job. I’m not keeping up my list as well as I’d like but I’ve begun listing some of my favorite collaboration team experts. I’m always looking for strong IT experts who are more than just individual contributors. It’s hard to find in our industry. I’m curious what tricks you are using to build your individual contributors into a technical team of experts?
I began writing this blog because I’m very interested in the direction of technology. I named the blog, “Modern Network Architecture” because as an IT Consultant I think we are in the midst of a major change in the way technical experts and business is thinking about technology. Continued »
This is a question I had recently and I struggled to solve a problem one of my Seattle IT consulting clients was having. You may have run into this yourself. You are the new IT vendor taking over the support responsibilities of a new client. You find something strange. After running a “Who Is” command on your client’s website you find… Continued »