IT Staff’s Major Headaches

IT is about day to day challenges. Most seasoned IT professionals have learnt how to deal with those challenges, which are all resource drainers. Here is my take on the current headaches of the IT department and possible ways to deal with them.
Users are one of IT’s biggest headaches as well as IT’s reason to exist. They become headaches in many different ways. The first type of user is who resists to change the application she is using. Resistance to change comes in many forms and this is one of the most prominent. IT staff should understand that changing an application means changing the way of doing things. On the other side, the users should understand that there is something like “supportability.” If the software vendor is no longer supporting that version, there is a need for upgrade. If IT does not upgrade, the user will get no support. Sorry, but the situation is really black and white and the only solution is communication.

Scott Adams clearly explains many of IT’s headaches in this cartoon.

The other type of user is un- or over-helpful. Sometimes the users simply do not help. I know there can be psychological reasons – losing hours of work for example – but it just gets on the way to solve the problems. The over-helpfulness sometimes block the effective working of the IT staff. An incident should be analyzed, problem steps evaluated and the possible reasons and solutions should be determined. The over-helpful user sometimes just blocks the steps by talking too much, offering tweaking applications or simply offering changing the corporate application. Again, there is no way except communication.

RELATED:   How Secure Is the Cloud? Will It Rain Personal Information Everywhere?

In the two cases above, I assumed that the situation is about a retail product, such as Microsoft Office running on a Windows Server. However, the users become harder to deal with if the application is an in-house developed application. When the company is developing an in-house application, the users have to be chosen to be engaged in early stages. They should be there when the application is being designed and prototyped so that they can embed the workflows and embrace the final product. When the product launches, they are good candidates to train their colleagues.
People are notorious for creating poor quality data. And they are also notorious for not correcting it. And they are also notorious for insisting to duplicate these data. And… you get the point. We all do it. We, humans are inconsistent. To overcome the situation, there should be guidelines for entering data and field validations should be introduced whenever possible.
Project management is another bleeding point of IT. No matter what new project management tools pop up everyday, no matter how your smartphone is integrated with them, no matter what getting-things-done techniques surface, still project management is not successful in IT. I see that there is just one main reason for failure: communication. Whether inter-department or the project team as a whole, lack of communication is clearly the premier reason. If you are a project manager, just stand up from your desk, walk around, speak with the end users and your IT staff and check the status yourself. Instead of taking people’s time to prepare daily status reports, go figure out what’s going on.

RELATED:   IT Pro: Missing Pieces in the Human Element

One of the products of an unsuccessful project management is unrealistic deadlines. Personally I look at if the project is finished and if yes, how. If a project is finished just because to say so, with many incomplete areas, key items left out, future enhancements are not mentioned, the project is not finished. I can say that almost 80% of the completed projects are in such situations. Sadly, the main reason seems to be unrealistic, extremely aggressive deadlines. With this, I am not implying that every project should be perfect. Rather, I am saying it should be “right.” The deadline should be reasonable, should take into account the possible delays and should be standing on its feet when completed. Imperfections can be worked out later.
Lack of documentation is a plague in almost all IT departments. Sadly, many of the IT executives do not consider documentation as of strategic importance. In a Microsoft seminar I have attended in January, the presenter told that %20 of people’s time are spent doing duplicate work. That means, in an IT department of 5 people, 1 person is always doing something a colleague has done, she does not know it and trying to do on her own. If the work were successfully documented, this time would be considerably lower. I say that, if the IT departments are trying to “do more with less”, documentation and training are the first two areas for investment.
The next headache is disintegrated tools. Cloud computing is on the rise, Software-as-a-Service offerings are taking the Internet and the mobile platforms by storm and the lines between the platforms are diminishing. Yet vendors insist on using their own management tools rather than providing their APIs (Application Programming Interfaces). If you want to manage an EMC VNX 5000 series storage system using System Center Virtual Machine Manager (SCVMM) 2012, you will understand what I mean: despite both sides use the same protocol (SMI-S) and despite that both sides have partnered to make the storage system work with SCVMM, it doesn’t. It simply is incompatible. To overcome such headaches, provide a proof-of-concept platform to both vendors and ask them for a working integration before committing purchase.

RELATED:   Feeling Insecure In Your Current Job Position?

One of the other headache is the people obsessed with a platform. There are system administrators who resist moving from UNIX to Linux with no apparent reason or there are the administrators who resist using another application. Both are the surfacing of the fear to change, but things do not work with fears. To overcome such hard times, assist these admins by providing the support and training they need. If they still resist, you may consider changing their roles to give support to the legacy systems. If there is no such case, you can encourage and assist them to continue their career in another company that uses/supports the same platform. It is best to address those situations before the project starts, otherwise lack of cooperation will plague the project even before the beginning.
Your headaches? Let us know in the comments.
References