Mentoring - The way to freedom

Over the years I have found myself often burdened with so many tasks that I couldn't do anything effectively. How did I get in this predicament? In a large part, this was due to my failure to mentor my staff.

A simple definition of mentoring is “One who guides without leading, teaches by example, and is willing to let the mentored one experience the bumps needed for learning and growth to take a place".

What qualities make up a mentor?

• The mentoring relationship is permissive not authoritarian. Mentors need to be good communicators and spend as much time listening as guiding.

• A good mentor can apply theory into practice.

• The mentor protects the mentee, and lets them fail or struggle. A world class athlete reaches there goal by overcoming failure, if we aren't allowed to struggle we don't grow.

• The mentee perceives the world in a new light. The mentor exposes the mentee to the decision process, and helps them see the bigger picture.

Benefits for Mentors

• This process keeps your thinking fresh, you are exposed to new ideas, and you have a finger on the pulse of employee perceptions.

• You develop new leaders who can work on your behalf, and carryout a shared vision.

• You hone your leadership skills, and receive personal satisfaction.

Benefits for Mentees

• Exposure to varying management styles.

• A greater understanding of the corporate vision.

• Access to good advice.

• Growth beyond your comfort zone.

Benefits for Organizations

• A unified vision throughout the management chain.

• Continuity in leadership, resources are developed within and retention is improved.

• Continuity of corporate values.

• A trusting culture is created, increasing effectiveness while motivating staff.

Downtime can mean life or death!

When I was in grade school I read a book about Ernest Shackleton the Antartic explorer. I was fascinated by his story of survival under the most brutal of conditions. Over the years when ever I saw something concerning Shackleton and the race to the south pole it caught my attention immediately.

Shackleton's expedition was a failure, they didn't reach there goal, and nearly lost there lives. It was only through courage and shear determination that they managed to survive. When you study the Shackleton expedition you find that the crew was ill prepared, there ship the Endurance wasn't well suited for the ice and eventually was crushed and sank. The Endurance crew being stranded, was forced to sail to South Georgia Island, hundreds of miles away in open life boats. Shackleton was also probably overly optimistic, and aggressive in his plan, taking on more risk than was necessary.

Often times I think IT projects are like Shackleton's expedition, they fall short of the goal, and a massive heroic effort is required to survive. Many times I have seen a change go into production that was said to be "transparent, no one will notice", twenty four hours later, sleepy eyed technicians finally get things back to normal. The technicians are applauded for there superhuman effort, and no lessons are learned.

The best IT organizations aren't always perceived as doing much, since they don't suffer these catastrophic failures. IT failures don't have the same life and death consequences as an Antartic expedition at the turn of the 20th century, but they can mean life or death to the business.

For a life and death survival give me Shackleton. For IT survival give me good planning and careful execution.

Baby Steps

Remember the Bill Murray movie "What About Bob", and how the therepy he was using was referred to as taking baby steps ? Today's blog concerns making small changes to your environment not the huge ones that crash systems and wreak havoc on user uptime.

Moving an organization towards a Service Delivery focus is a process of "baby steps". Make continuous improvements to your processes, measure what you are doing and establish base lines. You can start in a multitude of ways, I like to start with the Service Desk/HelpDesk. Funnel all of your issues through the Service Desk, and start reporting. Your incident management tool is where the information about what is not working lives. Start picking off problem areas and measure your results. How many critical sysytem outages are you having, track these over time? How many times do new programs go into production only to fail the next day? Begin doing code reviews before applications go into production. Are servers running out of resources unexpectedly? Measure these things and take steps to correct the issue. The key thing is to start picking off these issues, over time your IT life will become more manageable.

So what is Network Monitoring???

Network Monitoring

The term network monitoring, leads one to believe that we are only monitoring the network. In today's complex IT environments it is essential to monitor many things besides the network, a server running out of disk space, or a Windows service stopping can have drastic consequences for the organization.

Several years ago I started monitoring ethernet interfaces on routers with a tool called MRTG (www.mrtg.org), this was so easy to configure and provided so much information that I began using it to measure other things like Windows server statistics for cpu, memory, disk space etc... MRTG is still a fine tool but it requires a lot of manual scripting and was fairly hard to get configured for things that it wasn't built for. I began looking for other tool sets that were more easily managed and could provide notifications when a measurement crossed a certain threshold, it was then I discovered Nagios ( www.nagios.org ) . Nagios is a wonderful tool for notifications and is fairly easy to configure for monitoring most anything. I have combined this with Cacti ( www.cacti.net ) to provide graphing. Together these two tools can provide a very robust look at your environment, and they are FREE. If you don't have the skill set in house to install and configure these tools there a number of organizations that can assist with this for a reasonable fee, once up an running these tools require minimum maintenance and your staff can easily be trained.

Now, what do we need to monitor? I think most organizations miss the boat here, a server, or network administrator typically sets up these tools and only "points" them at there devices. When I speak about network monitoring I am talking about a comprehensive view of your environment. I start with connectivity, any monitoring tool has to be able to "ping" the devices in your environment. I typically start with the network interfaces, then the switches, and finally servers. Identifying these devices and configuring an up down monitor will let you know at a very base level what is working in your organization. Next I work on the notifications, who needs to know when something is down. Once again the administrators that typically set these things up, don't go far enough and not everyone that needs this information is included. Make sure and include you Service Desk, they are on the front lines, when something goes down a phone call from a non functional user is not far behind.

Okay, we know what is in our environment, if it's up or down, now lets start monitoring how well these devices are performing. For network devices, let look at things like bandwidth utilization ( how much traffic is going in and out of the device). Where possible you want to identify the ports on your ethernet switch infrastructure that are connected to your servers. This is often overlooked when setting up a network tool, this is valuable information and needs to be monitored. Once again we set thresholds and notifications for example 80% utilization on an interface may be a warning and 90% utilization may require a critical alert.

After configuring the network utilization, I start on server statistics. Each server in your environment should have at least the minimum of cpu, memory, and disk space monitored. We set up thresholds and notifications on these systems as well. Many other measurements are available depending on the type of server and the function that it performs.

Once the basic server monitoring is in place, begin looking at things like application performance.
This can be one of the most difficult things to measure but some creativity can get you through this. I have measured nightly processing by checking for the creation or modification of key or flag files at certain times. I know if these files are not there by the prescribed time that "production" is running behind, and send out the appropriate notification.

To maintain an accurate monitoring system you need to make this part of the installation and de-installation of anything in your environment. Make this part of your change management process, these monitoring configurations typically only take a few minutes to put in place.

With these very basic measurements in hand, trends can be observed that lend themselves to predicting things like a maxed out cpu, or disk space about to run out. This trending analysis is invaluable in budgetary planning. In many cases I have been able to predict months in advance when a system was going to run out of resources, this advance notices allows for proper planning and corrective action.

These are some very basic steps in building a network solution, for detailed information follow the links on my Resources page. If you have more questions please send me an email and I will respond as quickly as possible, typically within 24 hours.

Richard Skinner's groundbreaking book "IT is about the Strategy" is a comprehensive guide to developing winning IT strategies for the SMB.

Most young organizations suffer from the same breakage points as they grow. Skinner shows how these milestones and there accompanying issues are a normal part of business growth, and how you can overcome each of these challenges.

I have had the pleasure of working with Richard a number of times over the years, and I know these techniques work. His book outlines common sense techniques that will take you out of firefighting and chaos. If you are looking for practical help with your IT issues, please check out this book at www.itisaboutstrategy.com

The Daily Status Meeting

In most businesses we face IT issues on a daily basis, dealing with them in a timely, and effective manner is critical. I have found it extremely useful to meet with the IT staff each morning and review any of the issues currently open or, just recently closed in our tracking system.

We limit this meeting to just the critical service impacting events. Having this meeting early in the morning gives us a chance to get the necessary resources deployed to deal with the problem effectively. Including all of the IT disciplines is essential, make sure that there is a good discussion of the issue and review how process is being followed in updating tickets, and communicating with the users.This is perfect opportunity to drive the internal IT processes and get everyone on the same page.

Many of the things I do today have been gleaned from the morning meeting. Remember, we are always on the journey to better IT management, we however never arrive. Maintaining effective processes including incident and problem management is a continuous effort. When IT staff are not consistently directed they will fall back into old habits of poor documentation, and poor communication.

I also use this meeting to review any changes that went into production the previous day. This is the perfect time to check status on these items and it only takes a few minutes. A well run morning status meeting will typically take 15 to 30 minutes, certainly a small price to pay to know what is going in your IT environment.

This may seem overly simplistic, but you would be amazed at how many organizations do not do this simple task.

Are there babies dying?

With the recent turmoil in the middle east, there is indeed a situation where babies are dying. It is tragic to watch the news and see so many innocent children caught up in this tragic violence. Despite varying political views, no one wants to see young children suffer. We see rescue workers on both sides struggling to give aide to these victims as they place there own lives at risk. This is no doubt an emergency situation. The point of this post is to contrast these "real life" emergencies with the IT emergencies that we deal with.

On countless occasions I have been drawn into panic situations on the IT front, where it appeared as if certain doom was imminent, if the server wasn't back up right now. Managers are screaming, the phone rings off the hook, vacations are called off, and the world is on the edge of destruction, right? I worked with gentleman a few years ago, and while in the middle of one of these IT catastrophes asked "Are there babies dying?". This really hit home with me and helped me put things in the proper perspective. Large revenue impacting events are definitely important and should be responded to appropriately, but they are not on the same scale as the life and death events we see around us. Organizations find themselves in a panic first mentality which is counter productive, stressfull, and not cost effective.


In dealing with the IT emergency, some well thought out procedures can deal with the most critical events imaginable. The organization I work for had several incidents with hurricanes last year which required the shutdown of offices, rerouting of business, and the human task of getting money to people while the office was out of commission. We were able to do this, without undue stress, efficiently, and with some compassion. All of this was possible because we took time to plan, when the emergency arose, we new what to do.

Here are some really basic tips on disaster planning that we often take for granted.

1. Maintain an up to date contact list, with roles and responsibilities. It is amzing durng a crisis how hard phone numbers are to find.

2. Have a communication plan. Know who communicates with clients and who will manage internal communication. Let your staff do there jobs and have someone else manage communication. Know what you will do if all Internet, and telephone communication is shut off.

3. Prepare an escalation process, and make sure everyone knows how to use it.

4. Keep up to date inventories of equipment and software.

5. Backups, backups, backups. Enough said.

6. Document the chain of events. Use your incident management system if available to keep track of all activities surrounding the emergency.

7. At the end of the event, do a postmortem. Review the time line of events and look for things that could have been done better. Be critical of yourself, this will pay huge dividends the next time an event occurs. I found that sharing the weakness in our responses and a solid plan to correct them next time, adds credibility with clients and auditors. Don't be afraid of the truth!

In conclusion I would like to say that some cool heads, and basic management techniques solve problems faster, and more effectively than panic, and finger pointing. Remember the next time a server crashes ask "Are there babies dying?".

My server just crashed, now what???

The phone rings and on the other end is an angry user complaining that the system is down again. This is every IT persons nightmare, not to mention the user.

The IT person then scurrys around making phone calls, sending out frantic pings, hoping that the problem isn't in there area. System admins blame the network, network says there isn't a problem on there end, and send the problem back to the system admin, who in turn blames the programmers. What do you do? You reboot the box, when the box comes up the sys admins say they can't find anything in the logs, and it must just be one of those things. This happens about once or twice every 60 to 90 days. Does this sound familiar?

A system reported as down or crashed can mean many different things to IT, but to the user the system they depend on is down, end of story. Sometime systems crash or lock up and there is no apparent reason readily available, most of the time however there are warning signs and the mature IT staff will be looking for them.

This isn't an article on system administration, my point here is about monitoring what goes on in your environment. I shudder every time I here of a system locking up becuase of lack of disk space, 90% of the time this problem can be avoided by some simple monitoring and alerting. Monitoring will assist with other issues such as lack of memory, cpu, network traffic, or other errors. There is no excuse for organizations not doing network monitoring, There are free tools available. Nagios for example can be configured on a fairly low end machine and can track virtually anything that needs to be monitored. Nagios alows for alerts to be generated, escalations done, and has some rudimentary reporting which can show trending of uptime.


Having data available will help pin point problems much quicker. In the event of a server down scenario, a quick scan tell you what the network is doing, how the server was performing, and what if any capacity issues exist. With the setting of proper thresholds, most problems can be avoided before the user experiences a problem.

Most small businesses don't have good monitoring in place. If there is monitoring, it is done by different groups for there own particular needs, and a comprehensive approach is not in place to give everyone access to this vital information. Why is this? Poor managment. It is a management responsibility to make sure this infomation is available and regularly reported on.

Don't let your systems go unmonitored. Check out www.nagios.org this tool could save you thousands of dollars in lost production time. There are many other useful tools available, Nagios is the one I am most familar with, and in my opinion offers the most versatility. If you need help configuring Nagios, shoot me an email and I will help get you to a resource who can solve your problem.

Book review: Nagios: System and Network Monitoring by Wolfgang Barth

Read Jeremy Turner's review of the new Nagios book by Wolfgang Barth

Jeremy Turner reviews "Nagios: System and Network Monitoring" by Wolfgang Barth

ProjectSteps: A Collection of Project Management Sayings

Blogger Stephen Seay has assembled a collection of project management sayings that capture the thrill of victory and the agony of defeat experienced by the IT project manager.

Click on this link
ProjectSteps: A Collection of Project Management Sayings

What's in a project list?

I am always amazed when I go into a new company and ask to see the list of IT projects. Typically a spreadsheet gets produced with a wide variety of items that are typically 1-2 years old. When you talk to the admins, and programmers, they more often than not, have never seen "the project list".

Most small IT organizations have a huge back log of work that never gets done, the project list is more of a wish list! If you are going to move the organization along and get some of this strategic stuff done, you have to stay focused. Break these big projects down into manageable chunks and hold people accountable. Decide what is important and continue to drive forward, remembering that you can always find a small enough piece that can actually get done.

The other thing that amazes me is that many organizations have projects that make up a significant portion of there budget and there has never been a project definition, or scope defined. The project is underway, resources are being utilized, and a firm deliverable is nowhere in sight! If you have any of these "projects in the wild" stop right now.

While most small IT shops don't have budget money to spare, they continue to put resources into projects that will never come to fruition. I have seen several companies spend literally millions of dollars on the "system consolidation" project which will get rid of all of there core legacy systems and replace them with a new all in one system developed from scratch. I have yet to see one of these come into production.

Remember ...

Keep it simple.

Hold people accountable.

Identify the requirements, don't get caught in the "Ready, Shoot, Aim" game.

If you have a horror story of a "project in the wild", let me know.

Small IT needs structure TOO!

There is much buzz in the IT community about Service Delivery and frameworks, ITIL, COBIT and even Six Sigma are at the forefront. These are all excellent methods for improving the IT organization and aligning IT with the business, but are they appropriate for the small business? How do you implement ITIL if you are 20 person IT staff?

Small organizations can implement the spirit of these full fledged frameworks without being burdened by the weighty process inherehent in them. So where does one begin? Small organizations have to maximize there IT dollar, hence the goal of IT should be to provide a stable platform to do normal business operations, most of these processes don't contribute to a competitive advantage and aren't part of the core business. Applications like accounting, order processing, and inventory managment are commodity items and should be purchased out of the box. Take your time in selecting the right package and don't make customizations, adapt your process to the application. There are a scores of applications available that are relatively inexpensive, and have years of development behind them, you are not going to significantly improve on there overall performance.

If you are going to do software development, only do it when it contributes to the competitive advantage. Remember most software projects fail! I have never worked at an organization where the custom software apps have been delivered consitently on time, and within budget. Software development eats away at the precious resources of the small IT budget.

Infrastructure is another area where there is not a tremendous advantage. Put in good solid products, don't scrimp on quality, but don't do technology for technology's sake! Put you energy into figuring out the most efficent processes for your organization. When the issue is well defined, the soluton is doable. Find local vendors who can augment your staff with the high end resources you only need occasionaly, small firms rarely need a CCIE on staff, but paying for one's services when your are doing a network upgrade can save you lot's of moeny in the long run.

Capture what is going on in your organization, the IT help desk is the hub of IT communication. Once again there are a number of inexpensive tools to track tickets and distribute work. Review your critical issues on a daily basis, and look for repeat offenders. Utilize your ticket database to do reporting, this will tell you what is going on in your organization.

Monitor everything! Make it part of your infrastucture build to enable montitoring. Once again there are free tools available that will tell you exactly what is going on in your enviroment, and notify you when problems arise or are about to occur.

Manage change. Many small organizations feel that they can not take the time to do change management, this couldn't be farther from the truth. Remember most outages are caused by something IT changed. Start with a simple process, if it is longer than one page, it is too long.

These are just a few tips, upcoming posts will dive into detail on these steps and provide some specific examples.

Welcome, to IT for SMB

Hey,

This is my first shot at blogging, and I really am not sure what I am doing but...
I intend to make postings here concerning IT interests of the small business.

I have worked in IT for nearly 20 years, and I have struggled with all the classic problems that small organizations have, trying to do IT. After years of 60+ hour work weeks, I knew there had to be a better way to do IT, and I started to study not the technology but the "Strategy" behind IT. through this blog and my website www.itsd4smb.com I will share what has worked for me.