Congratulations, you have been hired into your first IT Manager role! Now what?

Most people in IT management roles have come up through the ranks in one of the technical teams. Oftentimes, individuals with exceptionally strong technical skills eventually end up in an IT management role. However, the transition from technical staff to management is one of the toughest transitions for IT professionals.

To help new IT Managers, we asked two regular IT management Joes—Joe Roush and Joe Hertvik—to provide practical advice on making the change from tech professional to tech manager. Here’s what they said and how it can help you with your IT management journey.

Align with strategy & goals

Joe Roush: Aligning IT capabilities with organizational strategy and goals is probably the most difficult aspect of IT management. Instead of all your focus being on server capacity or quality code, you must now look at how those technical solutions benefit the organization. Senior leadership will expect this of you now as well. You’ll need to learn to:

• Speak in terms of organizational benefit
• Describe IT investments as improving organizational capabilities

Any good investment ask should answer:

• What your team has built/accomplished thus far
• What you need funding for
• What the funding will do and how long it will take to provide results (Be specific!)
• How needed and great the results will be
• Which people have already made an investment (For instance, the team members who’ve done research or previously worked with those tools can talk about how this helped a similar project.)

Joe Hertvik: Unless you’re running a one-man shop, stop being the best technician in the shop. Your new job isn’t programming apps, configuring the network infrastructure, or setting up servers. Your job is to organize, strategize, define, direct, and control IT software and hardware infrastructure to do two things:

1. Enable, meet, and report on organizational goals using digital technology
2. Create value for the business

Instead of being a rock star technician, you’ll be guiding, directing, and coaching rock star technicians to create organizational value. You’re now a member of the management staff responsible for IT resources. It’s a significant and important perspective shift, but it’s a critical shift that needs to be made.

Invest in yourself

Joe Roush: New managers often feel overwhelmed with their new responsibilities. The single most important thing you can do as a manager is continually invest in yourself. I have found that the best way to increase your (and your teams) productivity is to keep learning:

• Read management books.
• Seek out professional development opportunities.
• Get a mentor and become a mentee.
• Ask for funding to go to conferences.
• Even writing helps.

Joe Hertvik: I agree you should invest in yourself and get more training. Give priority to sharpening your management-oriented skills to supplement your technical skills. Take IT project management training. Learn budgeting, reporting, coaching, staff management, and leveraging IT for strategic advantage. Read IT management articles along with tech journals.

Learn more about your organization’s core business, its needs, and how digital technologies can help fulfill those needs. Take any management training your business offers, so you can speak in the business’s language.

You’re in the wheelhouse now, not the engine room. Learn wheelhouse skills.

Measure and test—but experiment, too

Joe Roush: One of the most important measures of performance for an engineer is server or application uptime. That is why we spend time analyzing changes and test before moving to production. But this doesn’t work when you’re managing people.

I’ve seen managers hesitate to have one-on-one meetings with team members because they “were still studying how to run an effective 1:1.” The only thing worse than a manager who makes bad decisions? A manager who makes no decisions.

As a manager, it’s OK to try things out. It’s OK to fail (small). You don’t have to analyze every aspect of a management concept before trying things out on your team. Learn along the way. Ask your staff for feedback, listen to their suggestions, and never stop experimenting.

Joe Hertvik: As for measuring, you’ll still have to do some of that. You can use basic Agile principles to address application/server uptime and communication issues, even if you are using Waterfall development. Agile principle 8 states:

Working software is the primary measure of progress.

Ensure your deployments are well-tested and ready to go. Create contingency plans to use in case of a deployment failure. This applies whether you’re implementing a single feature in a sprint or delivering a massive waterfall deployment.

Don’t be afraid to experiment, but recognize that experiments can fail and burn down the lab. Make decisions and learn along the way. Identify risks and plan what to do if a risk comes true (risk response planning). Coach your staff to plan for both opportunities and risks when implementing new technologies.

Say “yes” the right way

Joe Roush: No IT manager ever said, “I have enough resources to accomplish all of the goals of the organization.” However, you don’t want to be known as the IT manager who says no to projects all the time.

As a manager, you need to understand the capacity of your current team and be confident enough to ask for additional resources when it makes sense. Your business leadership won’t respond well to you turning down a project request if you say “No, I don’t have enough resources.” However, if you say, “That is a great opportunity for us, and I’m excited to get going. To be successful I’ll need an investment in…” This allows the business to agree that it’s worth the investment—or not.

Joe Hertvik: Let’s looks at project management to underscore Joe R’s point about asking for additional resources rather than just saying no to a new request. Project management training talks about the triple constraint, shown here:

Under the triple constraint:

• Scope is what you’re trying to do.
• Schedule is the time frame in which you’re doing it.
• Cost is the amount of money or resources needed to deliver results.
• Quality represents the desired outcomes you achieve.

Any change to one of the three constraints will affect the performance of the other two. Adding features to a project scope for example, will affect your project costs and schedule. It may also require new resources.

The triple constraint provides a great template for explaining what the effect of a request will be on other organizational goals and objects. If you analyze each request in terms of what it will do to existing projects scopes, schedule, or costs (including resources), management will have enough information to determine if the new project is worth the additional investment. You would have management buy-in for adding those new resources (or pushing the schedule or changing the scope) rather than just saying you don’t have the resources.

When presented with new business opportunities, talk in terms of how each opportunity affects their current commitment—then let management decide whether it’s worth the investment.

Transition from technology to people

Joe Roush: As a technologist, your value to the organization comes from your in-depth knowledge of all things technical in your field. The more you learn and grow your skills, the more valuable you become and the more technical responsibility you will be given. This all significantly changes when you become a manager.

As an IT manager, you are responsible for the results of whatever technical team or individual you are responsible for. No longer will acquiring new technical knowledge provide the benefit it once did. Instead, you must look at skills of the team, determine what is needed, and who is in the best position to acquire additional skills.

Joe Hertvik: Agreed. Take inventory of existing skill sets and knowledge. Know yourself and your team. Reevaluate that knowledge against what the organization needs you to do and determine how to fill in the gaps. This will allow you to successfully manage project and product implementations, including digital transformations.

Build vendor relationships

Joe Roush: This was a hard lesson for me to learn. I always kept my distance from vendors and had operated with a don’t call me, I’ll call you attitude.

Believe it or not, most vendors really do want to help you. There are always a few that are only interested in making a sale. However, most vendors truly believe that their solutions will help make your organization more successful:

• Let your vendors know what technology problems you’re struggling with.
• Listen to their solutions and make your own judgment call about their proposals.
• Sometimes they’ll get it wrong, but more often than not, your vendors can really help you out.

Vendors appreciate being partners with you also. If you only call them when you have a problem, they’ll do what they can to help (and probably maximize their profit). However, if they view your relationship as a partnership, they are often willing to grant favors when you are in a pinch. They are also more willing to let you have input on new products or participate in beta testing.

Joe Hertvik: The right vendors are your friends. It’s impossible for most shops to have all the technical skills needed to perform all tasks.

Inventory and introduce yourself as the manager to all current IT organizational vendors. Get to know them. Evaluate what they bring to the organization and understand why they are doing business with the company. Contract vendors function as supplemental staff, so establish a relationship—you’ll need them for upcoming projects.

Listen (The answer is in the room)

IT managers are responsible for delivering results—not having all the answers.

Joe Roush: As a technician or engineer, you are expected to have all the answers for the technology you support. Many new managers believe that they, too, must have all the answers. When this happens, new managers will feel overloaded and stressed out, and no one can manage or work well under those conditions.

Managers aren’t responsible for having all of the answers. They are responsible for delivering results. If you could come up with all the answers, you wouldn’t need staff. Leverage their knowledge. Ask them to solve problems. You’ll be less stressed out, and your team will see that you value their input.

Joe Hertvik: I’ll repeat myself here. Stop being the best technician/programmer/engineer in the shop. As a manager, you’re responsible for:

• Defining direction
• Delivering results
• Keeping your stakeholders happy

Guide and coach your staff to implement the solutions you need. Part of being a manager is developing the people who are under you. Sharing the burden strengthens the bench. You’re responsible for the final decision. Learn to lean on your staff (internal staff and external resources, like vendors) to get the answers you need.

Don’t overlook problem employees

Joe Roush: Troublesome employees can be devastating to teams. Just because the previous supervisor didn’t deal with poor performing staff, it doesn’t mean you should do the same. You got your management job because you were viewed as a leader, so don’t be afraid to lead.

However, for new managers, this is one of the most difficult things to do. New managers still building their confidence often ask whether the employee in question is truly a problem or all that bad.

My litmus test has always been, “Would I expect my boss to allow that from me?” If the answer is no, then it’s definitely time to deal with whatever is going on.

Joe Hertvik: Make friends with your HR people and understand what organizational procedures need to be followed when disciplining problem employees. You’re not on your own here, and you shouldn’t be.

Evaluating employee performance can come with significant organizational risk. To minimize the risk:

• Make sure any actions you take fall within company standards.
• You may not need to use the big stick when correcting bad behavior, but you need to understand how to use the little sticks and carrots to improve performance.
• Seek guidance.

Become a rockstar project manager

Joe Roush: No one ever received a giant bonus because they kept the lights on. New organizational benefits are delivered by IT to the organization through new projects—but they also bring large financial risk to the organization.

If you are known as the IT manager who delivers projects on time, within budget, with the desired outcomes, you will never have trouble getting what you need. Added bonus: your IT organization will be viewed as an asset to the organization rather than a liability or cost center that can be cut when times are tough.

Joe Hertvik: Remember what we’ve discussed above and put it into practice:

• Align yourself with your organizational goals and strategy.
• Invest in yourself through education and training.
• Experiment with new technologies and plan for opportunities and risk.
• Work with management as a business asset, not an IT asset.
• Speak and act to create business value.
• Learn how to deal with your employees and vendor partners fairly and effectively.

Do all this and you will become a rock star project manager!

Additional resources

For more on this topic, explore these resources:

• BMC Business of IT Blog
• IT Leadership & Best Practices Guide
• Tech Books & Talks Guide
• 3 Steps To Aligning IT Goals with Business Goals
• Managing IT as a Product—Not a Project
• How To Create an IT Strategy: Getting Started

IT Infrastructure

I like to think of infrastructure as everything from wall jack to wall jack. Thinking of infrastructure in this manner enables effective conversations with those who are less familiar with the various components.

The term IT infrastructure is defined in ITIL as a combined set of hardware, software, networks, facilities, etc. (including all of the information technology related equipment) used to develop, test, deliver, monitor, control, or support IT services.

Associated people, processes, and documentation are not part of IT Infrastructure.

Switching

A network switch is the device that provides connectivity between network devices on a Local Area Network (LAN). A switch contains several ports that physically connect to other network devices, including:

• Other switches
• Routers
• Servers

Early networks used bridges, in which each device “saw” the traffic of all other devices on the network. Switches allow two devices on the network to talk to each other without having to forward that traffic to all devices on the network.

Routers

Routers move packets between networks. Routing allows devices separated on different LANs to talk to each other by determining the next “hop” that will allow the network packet to eventually get to its destination.

If you have ever manually configured your IP address on a workstation, the default gateway value that you keyed in was the IP address of your router.

Firewalls

Firewalls are security devices at the edge of the network. The firewall can be thought of as the guardian or gatekeeper.

A set of rules defines what types of network traffic will be allowed through the firewall and what will be blocked.

In the simplest version of a firewall, rules can be created which allow a specific port and/or protocol for traffic from one device (or a group of devices) to a device or group of devices. For example, if you want to host your own web server and limit it to only web traffic, you would typically have two firewall rules that look something like this:

The source is the originating device. In this case, ‘any’ means ‘allow any computer to communicate’. Destination is the specific IP address of your internal web server. Port/Protocol defines what type of traffic is allowed from the source to the destination. Most firewall devices allow for a description for each rule that have no effect on the rule itself. It is used only for notes.

Firewall devices can get complicated quickly. There are many different types of firewalls which approach managing traffic in different ways. Detailed firewall capabilities and methods are beyond the scope of this post.

Servers

A network server is simply another computer, but usually larger in terms of resources than what most people think of. A server allows multiple users to access and share its resources. There are several types of servers, with the following being among the most common:

• A file server provides end users with a centralized location to store files. When configured correctly, file servers can allow or prevent specific users to access files.
• A directory server provides a central database of user accounts that can be used by several computers. This allows centralized management of user accounts which are used to access server resources.
• Web servers use HTTP (Hyper Text Transfer Protocol) to provide files to users through a web browser.
• There are also application servers, database servers, print servers, etc.

Physical plant

The physical plant is all of the network cabling in your office buildings and server room/data center. This all too often neglected part of your infrastructure usually is the weakest link and is the cause of most system outages when not managed properly. There are two main types of cabling in the infrastructure:

• CAT 5/6/7
• Fiber optic

Each type of cabling has several different subtypes, depending on the speed and distance required to connect devices.

People

By the strict ITIL definition, people are not considered part of the network infrastructure. However, without competent, well-qualified people in charge of running and maintaining your infrastructure, you will artificially limit the capabilities of your organization.

• In larger organizations, there are specialty positions for each of the areas mentioned in this article.
• In smaller organizations, you will find that the general systems administrator (sysadmin) handles many of the roles.

Server rooms/data center

The server room, or data center in large organizations, can be thought of as the central core of your network. It is the location in which you place all of your servers, and it usually acts as the center of most networks.

Infrastructure software

Infrastructure software is perhaps the most “gray” of all infrastructure components. However, I consider server operating systems and directory services (like MS Active Directory) to be part of the infrastructure. Without multi-user operating systems, the hardware can’t perform its infrastructure functions.

Related reading

• BMC IT Operations Blog
• IT Infrastructure Management Explained
• IT Infrastructure Planning: How To Get Started
• Introduction To Load Balancing
• People, Process, Technology (and Partners): An Introduction
• What Is Software Defined Networking? SDN Explained

I’ve yet to see an IT group that is 100% happy with the level of communication it has with the rest of the organization. To help improve communications, many groups try and produce a regular newsletter to provide the boarder organization with more information about what’s going on in IT. If you are thinking about doing this in your organization, consider these tips to help make it worth the time invested.

(This tutorial is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

Make a Commitment

The need for a newsletter often comes as a reaction to some specific event. After all, how many times have you said, “if a user just knew x, we could have avoided this whole situation”? As IT professionals we are often predisposed to be a “fixer”. We see that end users don’t know something they should, so we immediately go into fix-it mode and try to blast out our vast amount of IT knowledge to the rest of the organization. The problem with the reactionary approach is that it is very difficult to maintain the initial motivation and momentum that comes from trying to fix a problem. A newsletter (or regular communication) is not a service desk ticket that must be resolved and forgotten. It is a commitment to providing communication to end users on a regular interval that will help them be more successful. Know this at the beginning and make a real commitment to publish on a regular basis. This means assigning specific tasks to specific people due on a certain date. Working on a newsletter “as time permits” will rarely lead to a successful outcome.

Help Don’t Tell

In order to create interest, you must be in the mindset of helping your end users. If you want end users to get better at password management, you must approach it from their point of view. Instead of writing about “password requirements for organization x”, put yourself in their shoes. Approach the situation from their point of view. If you need to, talk to a few people about why they are having trouble understanding the requirements that they need to follow. Then, you’ll be able to come up with a newsletter article similar to “Having trouble resetting your password, here’s three tips make it easier”

One other way you can approach this is to pretend that you are reading a newsletter from another group. As an IT professional, why would you read a newsletter from the finance department? Personally, I would only read it if I thought there was something relevant that would help me get my job done. I might actually read an article titled “5 tips for submitting your departmental budget.” Make sure you write to draw the attention of non-IT staff.

Have a Content Strategy

Your newsletter may ultimately fail or reach a narrow audience if you don’t plan your content well. Know what’s going on in the larger organization and line up your newsletter content to match. For instance, if you are going through an audit, include information that is relevant to helping end users meet audit requirements. If there are quarterly financial reports due, create articles like “how to leverage the company intranet to submit your reports on time”

When developing your content strategy, it can also be useful to vary your content throughout the newsletter. While you may follow a general theme “like meeting audit requirements” consider what types of articles can help meet compliance. You could have one article that is a “how-to”, one article that is a story about “how jane used data analytics to meet quarterly results”, and one that explains an audit requirement like “5 things you need to know about audit control 3.4.5.”

Use Imagery and Multimedia

I’ve seen so many IT groups try and create newsletters that were plain text (and boring), because the sysadmins and security don’t like HTML emails. If you want your IT newsletter to be read and be helpful it needs to be enticing and visually appealing. Include an image with each article that provides a visual representation of what the article is about. If possible, include imagery from inside your organization. For any how-to articles, include a short video clip walking users through doing something.

Don’t Make it too Long

Creating an IT Newsletter can seem very overwhelming at first. Start off small and build from there. It’s perfectly acceptable to release your first email newsletter with only 3 articles and a few helpful links. Get on a regular schedule of producing content, even if its small. Then, you can see if it’s too much or too little and adjust accordingly. Remember, you are making a commitment to regularly providing information to the organization. Build the habit within your team first. Then if you want to add more you always can. Creating a newsletter is a marathon, not a sprint. Don’t burn your team out early in the process and cause the newsletter to fail after just a few publications. It will take months to get your readership up.

Show Personality

Whether you realize it or not, your IT organization has a personality. If you don’t know what it is, ask around see how people categorize your group. Are you the “IT Overlords” or “The Nerds in the Basement” or the group that “Gets things done”? If you have a positive image, embrace it, an incorporate it as a theme in your newsletter. If you have a negative image use the newsletter as a chance to create a new image of what you want to be known for. For example, if your group is known as the IT Overlords name the newsletter something like “The facilitator” If you group likes to go out for lunch, you can even include a quick article at the end of your newsletter titled something like “We went to restaurant “x” for our lunch meeting…here’s what we thought.

The main point here is to let the organization get to know the IT group a little bit. Create a positive persona for your group. After all, IT groups are service providers, and enablers of business. It’s much easier to trust someone you know rather than trusting the “basement dwelling overlords”.

Talk About the Future

Include in your newsletter something about future projects or events that the IT group is providing. Business / IT alignment can be challenging in any organization. By talking about the future in the newsletter you enable a conversation about alignment. You might even have a VP stop by and say, “I saw your article in the newsletter about project X. I’m excited about the project and would like to hear what it does for our area” You might also hear “I read about project X and I’m not sure what its in line with what we are doing in sales. If you did project Y instead that would really help us out.

The newsletter won’t solve all your alignment issues, but it can play a vital role in creating the conversations that lead to better business alignment.

What is a Stakeholder, Really?

A stakeholder is anyone that has an interest in your project, process, product or service. This can include customers, project managers, vendors, outside regulators, VP’s, senior leadership or even co-workers. For purposes of this article, I’m going to exclude customers as a stakeholder. “Why” you ask? It’s because that I believe customer relationships should be approached in a different manner and thought of as a topic that stands on its own.

What do you mean by Relationship?

A relationship goes far beyond a business transaction such has a sale, or project delivery. There are 3 key components of stakeholder relationship:

Trust – Will you do what you say you are going to do? Can (and does) the stakeholder make business decisions based on what you have promised. Do you trust the stakeholder to deliver the support and resources that they have committed to?

Communication – Do you regularly let the stakeholders know what is going on? Do you keep them up to date? Do the stakeholders communicate with you and keep you informed on external influences that may affect your project?

Understanding – Do you and the stakeholder approach challenges with a sense of understanding? If something goes wrong, is the assumption incompetence, or do you and the stakeholder(s) assume positive intent of each other? Are you able to inform stakeholders of challenges without them assuming the worst?

The 4 Benefits of Stakeholder Relationships

Overcome unexpected challenges

The number one reason for building relationships with stakeholders is to plan for the unexpected. Every project, every initiative, will have something occur that is not expected. When unexpected problems occur without a relationship, it gives sponsors the feeling that you are incompetent. When unexpected problems occur with a relationship, sponsors have a feeling of confidence. Since I always like using construction analogies, here’s an example of what I mean:

Let’s say I’m getting some windows replaced on my house.

No Relationship Scenario:

Contractor says, “Well Joe, when I took your window out I discovered that there was some rot in the casing. It’s going to be a few hundred more to do this right.” My first thought is “why didn’t you plan for this? Surely, you’ve done a window install before. Why didn’t you tell me this could happen?”

Good Relationship Scenario:

Contractor says, “Well Joe, when I took your window out I discovered that there was some rot in the casing. It’s going to be a few hundred more to do this right.” My response is “well Jim, you’ve done work for me before and I trust your craftsmanship. Just do what it takes and let me know how much it’s going to be”

Reach compromises when needed

Seldom do we get to work on a project where we get everything we want, and everyone agrees on the work. Most of the time leading a project involves several conversations and compromises. Sometimes the key stakeholders will want the impossible. Other times they may be shooting too low. If you have built a good relationship, it becomes easier to have open honest conversations with your stakeholders. They’ll listen to your opinion and allow for flexibility in meeting the project goals.

Cut through bureaucracy, deliver faster

Have you ever been frustrated at the amount of time it took to complete a business process? Did that form you submitted slow down your project? If you talk to the senior leaders in the organization, you’ll find that for some reason they don’t experience some of the same delays you do. Most of us think that is because of their position in the organization, and sometimes that is the case. However, most of the time it is because of the relationships they have built in every area of the organization. They’ve had lunch with, been to soccer games, donated to causes, played golf with, had a coffee with, or shared a good time with at least one key person in each department. They can pick up the phone and say “hey bob, I submitted that form, but it’s been a couple days. Can you check on that for me?”

Take the time to build a relationship with people in other departments. You’ll be surprised what you can accomplish with the aid of a few allies. This will pay off in the long run when one of those allies ends up being a stakeholder on one of your projects.

Promise of future projects

If you have built good relationships with your project stakeholders (and potential stakeholders), they will keep you in mind the next time a project comes up.

Key Stakeholder Relationships

Vendors & Suppliers

Many of us don’t consider a vendor to be a stakeholder in our projects. If you are of the same opinion, then I would ask you to consider an alternate perspective and approach. If you have built a strong relationship with your vendors, then they are invested in your success. If you succeed, then they will also succeed through additional sales, and even marketing your project’s success. We’ve all read the whitepapers on how product “X” helped company “Y” accomplish “Z” goal. No vendor wants their product to be the reason a project failed. However, if you work with you vendors, let them invest in your success, and treat them as a stakeholder, you’ll find that they will act like a stakeholder and do everything they can to help.

Go beyond a partnership with your vendors, make them a stakeholder.

Investors & Shareholders

This is the most obvious stakeholder in your organization. Having good relationships with the people who directly invest your organizations success is always a good idea. However, the investor relationship can (and should) be slightly different. Oftentimes with your more direct stakeholders, project details bring comfort and trust to the relationship. Investors are usually more interested in the big picture. The key to having a good relationship with your investors is to start with the bottom line up front (or BLUF). Harvard Business Review has a great article on email communications using this method¹ Basically, when they ask how a project is going give them the one sentence summary. Then, if they ask for details provide them. This will show that you understand their time is important. By also providing the details (second) you provide them the information they need to reach their own independent conclusion. This communication style goes a long way towards building trust.

Other Employees

Peers in an organization are probably the most frequently overlooked stakeholder. While they may not be a key stakeholder and have a direct influence on your project, peer relationships are just as important. With a few exceptions, most employees want an organization to do well. A successful project means higher profits, better service, or efficiency in process (or at least it should). If your project does poorly, the health of the organization can suffer. Your peers may be able to help you out when you get in a bind if you take the time to get to know them and build a strong relationship

Government / Regulators

I have been involved in several organizations that looked at government or regulatory agencies as adversaries. With all the complicated policies and guidelines that must be followed, it can be easy to forget that they are actually people, getting paid to achieve an objective, just like you. Treat the regulators like the real people that they are. Get to know the names of key employees at the Agencey. Oftentimes you can get a “heads up” on a potential problem before it shows up in an audit report. If you approach your agency relationships this way, you’ll find your regulatory reviews will start going a lot smoother.

Potential Stakeholders

When is a stakeholder not a stakeholder? When they are a future stakeholder. I’ve been involved in several projects where the sponsor is the CIO or IT lead. I’ve also been on projects with HR directors and CFO’s as sponsors. I try to make sure I take the time to build a relationship with potential sponsors of future projects. Inevitably, in our conversations they’ll say, “What are you working on for Sally?” Don’t be shy. Tell them what’s going on including the challenges and how you overcame them. This is a great way to build trust and let them know what it’s like to work with you. The goal is to make the next conversation be: “I think you did a great job for Sally; do you think you could bring the same success to one of my projects?”

Project Sponsor

For most of us, the project sponsor is the senior business leader who has invested in your project. Oftentimes project leaders will think of the sponsor as “the person with the checkbook” and treat them as such. With this approach, one can unintentionally assume that the sponsor only wants to hear about what’s going well. I’ve seen more than one project manager hide challenges and try to resolve them on their own just to keep the sponsor happy. A good project manager may operate this way for years and do just fine. However, moving from good to great takes a different approach.

To help your projects go great, leverage the three concepts above (trust, communication, and understanding) to build a better relationship with your sponsors. Share what goes well and what doesn’t. Sponsors will oftentimes have the relationships in an organization to “pull some strings” and help remove any obstacles in the way of your project.

If you are reading this article, I’m willing to bet that you have just read your organizations previous strategic plan and are looking for some tips. Many of us have been through strategic planning processes that felt good in the beginning but became just another document that sits on the shelf. I’m a firm believer that in order for a strategic plan to be meaningful, it must also be relevant and have a direct tie to daily operations. Most importantly It must be executed not just created. My favorite quote on execution that applies to strategic planning comes from the Harvard Business Review

“ Execution is the result of thousands of decisions made every day by employees acting according to the information they have and their own self-interest¹

In other words, if the daily decisions of your employees do not align with the strategic plan it will never be successful. This article contains a few suggestions for making sure your strategic plan is a useful tool that guides your operations.

Consider a Strategic Direction

What is the difference between a Strategic Plan and a Strategic Direction? The answer is, decision making. Strategy by its very definition involves an overall picture of the situation. It is general guidance and should not be prescriptive. If your strategic plan has a list of goals you hope to achieve and then a defined list of projects that align with those goals from the very beginning, you haven’t put together a strategic plan. You have put together a project portfolio. Many organizations confuse strategic plan with project/portfolio plan. To get past this mental barrier, consider using the term strategic direction. This helps senior leaders conceptualize what you are trying to accomplish. It also encourages the team writing the strategic direction to stay “out of the weeds.” The responsibility of developing “plans” then falls to the lower levels of the organization. Not only does this provide room for innovation, it lets the departmental managers feel like they are a part of the overall organizational goals.

Be Strategic, but Operational

So many strategic plans out there are incredibly generic. Things like “increase shareholder value” or “invest more in research” seem to be included as a goal in every strategic plan. While we certainly strive to achieve these goals, they are very obscure. They don’t guide decision making. A strategic plan should be a tool that can be used to help the organization. A tool that doesn’t get used is a waste of time and resources. If you want your strategic plan to make a difference in your organization, it needs to be usable. Consider these example strategic plan goals:

Example 1:

Increase student enrollment by 10% by increasing the number of distance education programs offered by our institution.

Why it Works:

It tells everyone in the institution that they need to be spending time building online programs. It guides professional development activities. It guides IT purchases. It guides facility decisions. It also guides faculty who are developing courses. It lets department chairs create plans for which programs should be converted to an online format.

Example 2:

Decrease time to market by 10% through a 20% expansion of research and development.

Why it Works:

Everyone knows that decreasing time to market is a goal. They also have a target for how much they need to reduce time to market. The research team knows they are getting a 20% expansion. More importantly they know it’s ONLY 20%. HR knows they need to process more transactions, and what the reason for the increase is.

These two goals share a common theme: They allow people to make decisions in alignment with the goal without making decisions for them

Be Tangible

The strategic plan needs to be something tangible. Each strategic plan goal should have specific measurements that are easily understood. Defining measurable, tangible outcomes for your strategic plan should be one of your highest priorities. Leave as little room for ambiguity as possible here.

Many leaders are hesitant to document specific outcomes out of a fear of failure. Instead have the conversation ahead of time with the board. Establish a clear understanding of how they will hold you accountable to the strategic plan goals you set. More importantly, establish what benefits you, and you staff receive as a result of meeting (or exceeding) the goals. In other words, negotiate positive and negative reinforcement up front. If your team’s headcount goes down by one if you miss a goal, but everyone gets a 5% raise for meeting a goal, I guarantee you that your team will move mountains to save their peer and put some extra money in their pocket.

Your Focus Needs more Focus²

This is by far one of the most relevant business quotes I have ever heard in a movie. In the 2010 movie The Karate Kid, Jackie Chan is telling a young Jaden Smith that he needs to focus. Even though Jaden claims to be focusing on his skills he isn’t. This is exactly what happens in so many strategic plans, especially in large organizations. Many strategic plans are written at such a high level and have such a large number of goals that they are almost describing what the business does. We have operations guides and standard operating procedures to cover that. A strategic plan needs focus. The best plans have fewer that 5 goals that really provide focus for the organization. Narrow down the focus, not broaden it.

Reporting is Part of the Plan

Part of the strategic plan should include when you will provide status reports and what those status reports will contain. The reason we do this is to ensure that the plan is operationalized. If the board is expecting a report on the strategic plan, senior leaders will have to provide it. This means the plan gets reviewed on a regular basis and hopefully becomes a regular part of how you do business. I recommend quarterly reports on the strategic plan. Waiting a year to report (as many plans do) give everyone the opportunity to forget about the plan. If you can’t get agreement to report out quarterly, settle for bi-annually, but no less frequent.

This article takes a look at a few of the different types of roadmaps and provides some samples that you can leverage in your own strategic planning initiatives.

What is an IT roadmap?

Before we can start talking about roadmaps, we need to understand what one is. An IT roadmap is a strategic tool that can help graphically illustrate both long-term and short-term plans. In short, it says where you are and where you plan on going within the next few years. There are several different types of roadmaps depending on what area you want to chart a course for.

Let’s take a look at:

• Service roadmaps
• Infrastructure hardware roadmaps
• Strategy roadmaps
• Technology roadmaps

Service Roadmap

The service roadmap is focused on the IT Services that you provide the organization. These can be especially useful when explaining what services you plan on retiring or spinning up over the next few years. The service roadmap contains a list of all your services. It allows you show at a glance:

• The services you are spinning up
• The services you are maintaining
• Which services are in preparation for retirement
• The services that will replace any services that may be scheduled for retirement

Let’s look at some great examples of service roadmaps.

University of Michigan

One excellent example is from University of Michigan. They have developed a concept called a Michigan Enterprise Strategic Assessment (MESA). This is one of the few examples I have seen that breaks the traditional graphical “Gantt style” representation of a roadmap. They instead plot services on a curve that provides a lot of information at a quick glance.

Take a look at the U-M example.

University of South Carolina

Another great service roadmap example comes from the University of South Carolina, University Technology Services. They take a different approach in presenting their roadmap. This example shows three main areas of investment as well as what efforts they have deferred. It also provides a great example of what technologies they are retiring, and which ones will be taking their place (if any).

This example is great for CIOs to get a perspective on all of the systems they are responsible for. View the USC example.

Infrastructure Hardware Roadmap

An infrastructure hardware roadmap is focused on the infrastructure equipment in service. This type of roadmap is my favorite way to show senior IT leadership when specific models of gear will be retired.

The infrastructure hardware roadmap is best used for areas where you have a large amount of equipment. This one also works great with any spreadsheet application.

One Example

The first column is a list of models of equipment. The second column is the number of that model you have in service. Then, there are additional columns for each fiscal year in which you want to show your intent for that model. Then you color code your intent for each fiscal year. I like using four different colors.

For example:

The technology roadmap lets you see a great deal of information at-a-glance. In our example above you can tell that the Model 5000 switches are being phased out in FY20. However, we are going to keep buying the 7000’s until FY22. For firewalls, we have a contract decision in FY21 and FY22.

In this example I used network switches and firewalls. However, it also works for servers, storage or any component of infrastructure that has a high item count and needs a defined lifecycle.

Strategy Roadmap

A strategy or sometimes called a strategic intent roadmap lays out the work ahead based on the strategic goals of the organization. This type of roadmap provides an excellent way to visualize your strategic plan.

In most roadmaps of this style, the organizational goals are on the left side of the roadmap with a Gannt style timeline that describes the implementation timeline. If there are several supporting projects that role up into a larger strategic goal, you can show those individually as well.

Saint Louis University

Saint Louis University has done a very good job with their Strategic Technology Roadmap Summary. This example follows the Gannt style chart. It has a listing of all their IT projects and which goal they align with. They have also added color coding for project status. This is an excellent addition that gives leaders some indication as to which goals are at risk. The only thing missing from this great roadmap is a timeline summary for each goal.

Consider using Saint Louis’s roadmap next time you are presenting your strategic plan to an executive committee or board of directors.

Technology Roadmap

The technology roadmap typically displays various projects that support technology stacks within your organization. This type of roadmap is typically very high level and is great for demonstrating how your products align with your overall technology portfolio. This is similar to the strategic roadmap.

However, rather than being focused on the strategic goals of the organization, it more closely resembles your organizational structure. If you want to see what your network team, Applications, service delivery and other groups have planned at a glance, then the technology roadmap is what you are looking for.

Smartsheet’s Free Roadmap Templates

While Smartsheets offers their own tools for creating roadmaps they have links to several templates that can be used with other products.

I especially like their technology roadmap. It has separate grouping areas for each technology area and also incorporates service quality and trends. It does a great job of combining projects that may not directly align with one it area and projects that do. Best of all, the template is available for download and can be used with your favorite spreadsheet application.

Wrapping up IT roadmaps

As you can see, there are several different types of roadmaps that can be used depending on your situation. I have listed just a few examples here, but there are many more to choose from. You may also find roadmaps that are categorized different than what I have presented. Regardless of what type of roadmap you choose, remember that communication is what the listener does. Know who your audience is for your roadmap and make sure you choose a roadmap that aligns with their interests.

Related reading

• BMC Business of IT Blog
• BMC Service Management Blog
• IT Management: Get Started with Help from Two Experienced Joes
• IT Strategic Planning: Why is an IT Strategy So Important?
• IT Project Management: Concepts, Solutions & Best Practices
• IT Spending Trends Today

Customer Service and Technical Support both have their roles in organizations. However, there are significant differences between the two.

• Customer Service focuses on the experience of the customer.
• Technical support focuses on resolving a technical issue or problem in the fastest, most cost-effective way.

What is technical support?

Business Dictionary defines technical support as:

“User-friendly assistance for individuals having technical problems with electronic devices.”

The primary focus of technical support is to resolve a technical incident or problem. These incidents are either perceived or actual deficiencies with the service or product the customer is seeking support for. That’s why it behooves the technical support engineer/representative—and the company—to:

• Determine what is not functioning properly
• Resolve the issue as quickly
• Maintain a friendly and supportive vibe

In most situations, the ultimate measure of success is that the customer doesn’t have to contact support again.

What is customer service?

Customer service takes a different approach, focusing instead on the experience of the customer. Customer service, according to Business Dictionary, is defined as a:

“Range of services provided to assist customers in making cost effective and correct use of a product.”

This means that a customer service representative can also take a more proactive approach to support and initiate communication with customers. Importantly, customer service does not have to be technical in nature.

Different customer approaches

Because your goal varies, your approach when interacting with a customer likely varies, too.

• Good technical support means listening in order to fix. A technical support representative is focused on resolving your issue as quickly as possible. Technical support reps listen to symptoms, try to reproduce the issue, and quickly provide a solution to the issue.
• Customer service reps listen with empathy. They put themselves in the “shoes” of the customer and try to understand what the customer is trying to accomplish. They aren’t listening to fix they are instead listening to recommend. This could be recommending a new product, or different approach.

Different product perspectives

When discussing the difference in perspective, I like to use what I call the “word processing example.”

When you contact technical support about an error in your word processor, they can always help you resolve that error dialog box that pops up. They can also help you figure out what plugin isn’t working and remove it.

However, when you say, “I’m writing a paper in APA format and I need to know how to make the first page header different than subsequent pages,” technical support will probably come up short.

This is where customer service steps in and can offer distinguishing value. Customer service means knowing what the customer is going through and helping to find a solution.

Continuing with our example, a good customer service rep would understand what APA format means. They will also know that if someone is asking questions about how to write a paper, they are probably rushed and on a tight deadline. If your customer service rep don’t know the answer right away, the rep knows how to get customers in touch with the right resources.

Technical support is dead. Long live technical support.

You should consider adding customer service practices to existing technical support groups.

In the late 90s and early 2000s, skilled technologists were more difficult to find. Back then, it was easy for organizations to stand out by providing high quality technical support.

Nowadays with the conversion to digital business, technical competency is much more mainstream. Customers want to have great experience with your organization. They are interested in partnerships that go beyond the initial purchase. They want to know that you understand their goals and that you can help them accomplish them.

In other words, they want to have a great experience with your organization.

Customer service best practices

At this point you are probably wondering just what customer experience is. Simply put, customer experience (CX) is customer comfort. Comfort is a general feeling that the money and time you have invested in a product or service is worth the value received.

There are many components that lead to customer comfort. The list below are the ones I try to focus my teams on.

Empathy

Support representatives need to provide the customer with a sense of understanding. The customer should feel like they are working with a partner who understands the problem from their point of view.

Ideally, representatives working with customers should have at least a basic understanding of the industry they are supporting.

Competence

The #1 expectation of any type of support request is that the person providing assistance knows the product inside and out. There is nothing that erodes customer comfort faster than fumbling through a support call.

This also means if representatives don’t know the answer to a question, they should admit it. Saying “I don’t have the answer but I can get it for you” will be much better received than pretending that you know an answer.

Friendliness

No one likes to work with a jerk. Representatives should strive to solve customer challenges in a friendly way without over-doing it.

Communication

This is another extremely important aspect of comfort. At all times representatives should make sure a customer knows four things:

• What is the cost of support?
• What work is occurring to address their issue?
• What will you be working on next?
• What is the current ETA for completion of work?

As long as customers know those items, they will usually be much more comfortable.

Offer of assistance

Support representatives should always ask what they can do to help. Don’t ever assume you know what the customer wants. The best way to learn, is to ask.

CX becomes critical

A 2015 Gartner survey revealed that an overwhelming majority of companies believe that customer experience is the new basis for competition. And, according to Salesforce, “86% of buyers will pay more for a better customer experience.”

While there will always be a need for technical support, IT organizations should evaluate if their support solutions are really meeting the needs of their customers. Are you just supporting a product or are you providing an experience for your customers?

Related reading

• BMC Service Management Blog
• Help Desk vs Service Desk: What’s The Difference?
• Service Desk Best Practices for Creating More Value
• Internal vs External Customers: How Are They Different?
• Service Desk Support Analyst: Roles and Responsibilities
• 5 Ways to Deliver a Transcendent Customer Experience

Why Engage in Infrastructure Planning?

Very few of us are lucky enough to be one of the first few employees in a new organization. Those of you who are get to plan the infrastructure with a blank slate, and can focus all of your efforts on doing things right the first time. However, most of us have inherited an infrastructure that has at least a couple of components that we would do differently if we had the opportunity to do so. Making changes to your organizations existing infrastructure can be thought of as trying to redesign your house while you still live in it. If it isn’t done correctly you can inadvertently put your most prized possessions at risk.

This audience for this article is for those of us who know that we need to make changes to our infrastructure but are not sure where to start, or how to ask for funding to do so.

Map your Infrastructure to Business Success Metrics

The most important thing you can do to prepare for your infrastructure planning is to make sure you understand what your organization is trying to accomplish. This is a deeper dive than just understanding the mission statement. You need to be able to map infrastructure components and systems to organizational results. Talk to your senior leaders and see if you can find out what metrics they use to measure organizational success.

Primary Driver – The infrastructure component that is directly responsible for enabling change in the business metric.

Secondary Driver – The infrastructure component(s) that primary drivers rely on.

A couple Examples:

A website (running on a web server) directly enables the organizational ability to process sales transactions. Because the web server relies on networking and data center facilities, they are considered secondary drivers.

The network allows call center employees to send / receive calls (remember endpoints are not infrastructure). The ability to receive calls affects # of new customers as well as customer retention rates. Therefore, PBX/ Phone system (including the network) is the primary infrastructure driver of # of new calls in this scenario, data center facilities, and servers are secondary drivers.

The best test for determining a primary / secondary driver is by asking the question:

“Does an investment in this component allow the organization (not the IT department) to do something it couldn’t do before?”

Keep in mind this is not an exact science. You could also argue that the servers running the phone system are primary drivers and others are secondary.

The main point here is to help you think about your infrastructure in terms of its ability to affect the business.

Here is one example of what that map could look like:

Set Priorities around Primary Drivers

Setting infrastructure priorities is often the most difficult thing to do for organizations. After all each part of the infrastructure relies on all of the other parts, so it is all the most important, right?

Not exactly. In the 1990’s our infrastructure design goal was to build in as much redundancy as the organization could possibly afford. The more redundant the better. While additional redundancy is always beneficial, infrastructure is much more complicated than it was back then. Organizations simply can’t afford to take every component of their infrastructure to 99.99999 (5 nines) of reliability and remain profitable (except for some industries).

Only by understanding the primary infrastructure drivers of our organization, can we set priorities around our infrastructure investments. Let’s revisit our previous example:

If our online storefront is a primary business driver, then this is where we need to focus our planning effort(s). Do a deep dive to understand all of the infrastructure components that the storefront relies on. Answer questions like:

• What is current capacity (#of visitors, #transactions processed..etc)
• Is the infrastructure meeting capacity?
• How many servers / vm’s does the current configuration use
• How much storage is required?
• What is the expected utilization rates over the next 6-12 months

Consider Alternative Options for Secondary Drivers

As the pace of change continues to increase, it is more important than ever that organizations develop deep talent in areas that drive their business. Secondary drivers are great areas to consider how you could leverage outside help. Ask yourself questions like:

• Does our online storefront really need to be in our datacenter?
• What would happen if we moved it to the cloud? Would that reduce complexity?
• Do I have business partners that could host my servers?
• Can I increase performance and reliability of these secondary drivers by leveraging specialized consulting firms?
• Are there other areas in my organization (parent/sister companies) that are experts in these secondary areas?

Draft a 1 year infrastructure improvement plan

Now that you know what components of your infrastructure are most effective at driving business results, you can begin to put together a plan. There are a few key areas in infrastructure plans that senior executives really like to see.

Plan / Executive Summary

I’ve heard so many infrastructure managers say “I’m not writing an executive summary because it doesn’t say anything important” I always respond to that statement with “Well, this time lets write something important in it”

The executive summary isn’t really a summary of the whole plan. It is your elevator sales pitch. Executive time is valuable. Most execs will pick up a planning document, glance at the first page, see if anything catches their eye, and then turn to the last page, which has a grand total of how much money you want. If you didn’t get the first two sentences of the summary right, you are relying 100% on your relationship with that executive for plan approval. He or she will make the decision to fund the plan based on their perception of your value in the organization. If this is your first big project, you don’t stand a chance of getting it approved without a solid executive summary.

An opening sentence like “This is a plan to increase our sales capacity by x% by making an investment in our X infrastructure. This additional capacity has the potential to increase gross revenue by y amount of money.

Even if your numbers are a little off, most execs will say “this infrastructure guy/gal has their head in the right place, I’m going to take a look at this plan.”

Priority Investment Areas

This section contains “the ask.” How much investment do you need and what are you going to do with it. Talk about your primary drivers and how these investments have the potential to improve the organization. This area should also include summary details of what you need purchase. Number of servers, storage capacity, and data center renovations…etc.

Change Opportunities

What parts of the infrastructure should be changed, but require little to no investment? Things like operational procedures and repurposing underutilized or misconfigured components go here

Efficiency Opportunities

What do you plan to stop doing in the infrastructure? What technologies are no longer needed and should be decommissioned. What legacy gear has been causing problems and how will it be removed from the infrastructure.

Draft a Longer 3-5 Year Infrastructure Plan (Every Year)

What you say, draft a 3-5 year plan every year? What sense does that make?

Before we answer that question let’s talk about why we are creating our first 3-5 year plan AFTER finishing a 1 year plan.

You will learn a lot about planning as well as your organization that first year. Take the time to understand what worked and what did not. Many infrastructure managers will try to change too much too quick. Alternatively, they will realize that they got too far into the weeds in that first plan and got very overwhelmed.

Use the information and experience gained in that first year to prepare for a larger, longer plan that sets a direction further out into the future.

So why do we want to draft a 3-5 year plan every year? Because everything changes. Organizational goals change, technologies change, staff expertise changes. IT departments must be able to adapt to those changes. You have to be grounded in the present, but have an eye towards the future. By adjusting our plan every year, you’ll do a much better job of knowing what needs to be done now, to align to that 5 year vision.

You may even decide you want to try a new approach to planning your infrastructure. I say, “That’s great!” The point is that you learn from your experience, adapt, and execute a planning process that delivers results for your organization.

Everyone who has ever been a systems administrator or infrastructure manager has at some point experienced server sprawl. Over the past few years, technologies like virtualization, Docker and cloud services have come along to help address this challenge. Nonetheless, at some point either someone is going to say “do we really need all those servers? Surely there are at least a few that we can turn off?”

This article isn’t intended to stop server sprawl from occurring, but rather how to address it once it has occurred. While it may seem easy to just go into the data center (or VM console) and identify what can turn off and what needs to stay, oftentimes however, it isn’t.

1. What problem are you trying to address through server consolidation?

Like most projects, the scope on a server consolidation project can creep out of control if it is not managed properly. This is largely because there are several strategies that can be employed to reduce the quantity of servers in an organization. Because of this, it is critical to know what problem you are trying to solve first, and then decide on your consolidation strategy. Some common reasons to begin a server consolidation effort are:

• The administrative burden of several servers exceeds your staff’s capacity to manage them
• Two or more organizations have merged and there are too many servers performing the same functions
• To prepare for a move to a new data center
• Reduce cost of server operation
• To reduce the organization’s risk exposure
• To prepare for hardware lifecycle replacement
• Applications and their underlying infrastructure are ready for decommissioning.

2. Take inventory of all your servers (Physical and Virtual)

This seems like a no brainer, but I’ve been part of more than one project where additional servers were discovered as part of the consolidation project. It is incredibly important to understand the current state and quantity of servers for a given function, so that you can create a vision for the desired end state. Below is a sample of what each record in a server inventory could look like:

It is important to not make this inventory more complicated than it needs to be in the beginning. While your technical teams will need to know things like external IP addresses, firewall rules, RAM, Storage, and CPU type, at this point you only need to know the basics. Once you have a basic inventory together, you can move on to categorization (for purposes of consolidation)

3. Categorize the functions of your servers

This is another one of those items that seems relatively easy. Every systems administrator groups their servers in one way or another. What is needed for a server consolidation effort is a consistent grouping system that is followed and understood by all project assignees. Below is an abbreviated list using two grouping methods within a grouping system. By having multiple methods within a grouping system, it is possible to evaluate consolidation opportunities in different ways.

Grouping by Function

Grouping servers by function lets you evaluate consolidation opportunities based on similar workloads. By looking at one group at a time it becomes easier to evaluate what servers could be combined. With this method, ask questions like:

1. Are all my servers in this grouping close to %80 utilized? If not, what workloads could be consolidated?
2. Are any of my servers in this grouping overutilized?
3. Is there business or application reasons to keep servers within a function separated? If not, does it make sense to combine them?

Grouping by Security Profile

Grouping servers by security profile allows you to incorporate risk management into your consolidation effort. It also provides a check and balance to your function grouping to help ensure you don’t create security problems by consolidating server workloads.

By grouping servers together based on security profile, you can ask questions like:

1. Should all my servers in a security level be kept together?
2. Does it make sense to consolidate “server 1” and “server 2” if they have different security levels?
3. Can I reduce my cost of risk management by isolating the most private servers and increasing the security controls on just these servers?

4. Look to cloud options

Moving to the cloud can have a significant impact on your overall consolidation effort. There are many workloads that can be redesigned to leverage the advantages of moving to the cloud. However, if your focus is server consolidation, and you are looking to take your first steps into the cloud, collaboration suites and storage are a great starting point without having to invest too much development time. Office 365 and GSuite (and others) can significantly reduce the number of servers in your organization by eliminating the need for email and file servers.

Other great options for moving to the cloud are any client server applications that you have purchased over the years. Most software providers now have cloud options as well as professional service offerings to move from your on-premises version to the cloud version.

If you find opportunities to move in-house developed applications to the cloud, great! However, I highly recommend treating these efforts as separate projects that stand on their own. More on this later.

5. Virtualize everything that’s on-premises

I’ve been involved in virtualization efforts since the early 2000’s. There was a point in time where it was considered bad practice to virtualize databases and domain controllers. However, modern virtualization solutions make these old arguments irrelevant. A properly architected virtualization solution will allow you to virtualize almost every server you are hosting on premise without fear of a server apocalypse. If you provide adequate resources for your virtual machines there is no reason to keep physical servers around anymore (except for the hypervisor hosts, obviously). A fully virtual environment will also allow you much more flexibility with your server consolidation efforts.

6. Write your Consolidation Plan

Now that you know what you are trying to achieve, have grouped your servers, evaluated cloud options, and virtualized as much as possible, you are ready to write your consolidation plan. How you write your plan will be different for every organization. However, at a minimum your consolidation plan should have the following sections:

1. Background / What problem you are trying to solve
2. Current server count / cost
3. Future Server count / cost
4. Timeline for consolidating moving servers
5. Which servers will be decommissioned
6. A section on what success looks like at the end of the project.
7. Sign off from senior IT management

What to Watch Out For

Any time a server consolidation initiative involves an application redesign, it’s a major red flag. I’m not suggesting that application redesigns are bad, or that organizations should not redesign an application when there is an opportunity to find efficiencies. I’m suggesting it’s a bad idea as part of a server consolidation project. Here is why.

Most application redesigns involve spinning up new servers to host the new redesigned application. In larger environments, this includes development, test, and production servers. Then the application developers should design the new system, perform all the testing required, and then move production to the new system. Next, the old environment must be decommissioned, which includes determining the disposition of the data in the old system, if not all of it was migrated. There are just way too many variables in an application redesign for your server consolidation project to depend on it. I’ve even seen the server count go up instead of down when application redesign is part of server consolidation.

Again, I want to reiterate, it’s usually a good idea to redesign applications when there is an opportunity to leverage new technology or reduce the resources consumed. However, an application redesign project should stand on its own and be a separate project from your server consolidation.

This article is written from the perspective of an IT Strategy in higher education. However, many of the concepts can be applied to any strategy communications plan. Keep in mind however that the IT Strategic plan has an organization-wide impact. Because of this, the approach to communicating the IT strategy should be treated just like an organizational strategic plan.

Perhaps the largest barrier to the adoption of any strategic plan is belief in the plan. I’m a firm believer of “You can’t assign a strategic plan. People have to believe in it to achieve success.”

My favorite example of a successful strategy that employees believed in is Ford Motor Company’s 1982 “Quality is Job One” campaign. In 1982 the public believed that other auto manufacturers were building much better cars than Ford. To address this, Ford started a campaign/strategy to change that image. What most people don’t realize is that “Job 1” inside of ford refers to the first car of a new model that is produced. By stating “Quality is Job One”, Ford made it very clear to its employees that the first car off of the line (and implying every car thereafter) should be of high quality. This simple easy to understand strategy to improve quality resonated internally with employees and externally with customers.

Now not all of us are going to achieve the level of success in our IT strategy that Ford did. However, what we can do is ensure that we craft the message of our IT strategy so that it resonates with, and is easy to understand at all levels of the organization. Having a robust communications plan is vital to that effort.

Know Your Audiences and Stakeholders

Knowing your audience and making sure they get the right message is the most important and perhaps the most overlooked component of any communications plan. What’s important and what resonates to a Dean or VP, is very different than what’s important to a systems administrator. Your IT Strategy communications plan needs to include a message for both of these audiences (and many others).

Once you understand who your audience is, you need to know what to ask them for. A dynamic leader and good storyteller can get some initial interest in the plan. However, the first question that always gets asked is “what does this mean for me” Consider creating a table like the one below to help you understand how to answer that question.

Understand Your Communication Culture

After you understand your message, you need to consider how to communicate that message. Different audiences likely communicate via different methods. The next thing to identify is what are the successful methods of communication in your organization for each of the audiences. Take inventory of what tools/ media exist. Identify things like:

• Is there an organizational intranet? If so, which audience uses it the most.
• Do people actually read the organization-wide emails? If so, who do they come from?
• What physical communication tools exist (bulletin boards, break room postings, digital signage, etc.)
• Who prefers face to face conversations?
• What meetings should the plan be presented at?
• How do you get a message to your senior leaders?

Most importantly, have your elevator pitch memorized and available at all times for each of your audiences. Oftentimes you’ll find yourself in a lunch line, on public transportation (or actual elevator) with a VP or key decision maker. Have a pitch, or an ask ready to leverage when the opportunity presents itself. Even simple questions can go a long way. Here’s one example:

“Good afternoon Mrs. VP, I’m having trouble reaching the other VP’s to talk about our IT strategy. Do you have any suggestions on how I could reach them?”

You will likely get responses such as: “I’ve heard about that strategy, what’s the short version” or “Sure, reach out to my assistant and He’ll get you on our next VP meeting agenda.”

Most senior leaders are willing to help; however, they are extremely busy. Having a message ready for the right moment can really go a long way.

Identify Your Key Influencers

Every organization has the official reporting structure and has the informal one. There are people in every organization who seem to be better at getting things processed, and whose ideas get listened to. Know who these people are and understand their sphere of influence. Especially in higher education. Almost every academic department I’ve ever worked with has that one faculty member who is highly respected and seems to be able to go around organizational boundaries. Take inventory of these folks and seek to obtain their support for your IT Strategy. Sometimes you can even ask them to send out a strategy communication for you. People throughout your organization are much more likely to adopt your strategy if they see that their peers support it as well.

Obtain a Broad Range of Input

This is often the hardest one to do. An IT Strategy that gets adopted needs to have the support at all levels of the organization. The most effective way to ensure that people feel a part of the strategic plan is to let them help contribute to it. At the same time, however, you can’t have 200 people write a strategic plan. To gain input, establish your method of obtaining that input ahead of time. Consider how you can leverage things like:

• Town Hall meetings
• Organizational committees
• Individual Meetings
• Senior Staff Meetings
• Lunch and Learn sessions
• Surveys
• How you can recognize individuals for their contributions

As the final versions of your plan are rolled out, be sure to mention everyone that contributed. Not only will this give more weight to your plan, but it will create a broader sense of ownership. If you take a look at my previous article (5 Great Strategic Plans and Why you should read them) you’ll see most of these recognize all of the contributors.

Document Who is Communicating What, and When

The last thing to consider as part of your communications plan is who will communicate, what message via which communications media. Earlier we talked about our audiences and what message we need to get to them. I also discussed learning how they like to be communicated with. Consider building a communications plan chart like the one below: