After Hours optimize

10 of the biggest IT sand traps

Many of the issues plaguing IT departments can be mitigated or sidestepped altogether. Here are some ways to deal with several common pitfalls.

IT faces challenges on a daily basis. But most experienced IT'ers have learned to avoid the worst sand traps so they can prevent time and energy drains. What are today's biggest IT sand traps -- and what best practices can you use to circumvent them?

1: Uncooperative users

Uncooperative users are still out there, as they have been through the years. Most don't cooperate out of fear of a new application -- or because of a comfort level with a present application that they don't want to give up. It is important for IT to remember that when it changes an application, it also changes a person's daily workflow. This can be disconcerting, even for younger users. The key is to engage users in application dialogues at the very beginning. Involve them in early app design and prototyping so they already know and buy into how the app is going to work before it is ever plugged into production.

2: Unhelpful users

Unhelpful users are trickier to work with because they frequently come in the guise of "helpful" individuals who cross a threshold when they become too helpful. They offer reams of tweak suggestions for apps and never want to accept an app as being complete for a given release. Enhancement creep of this nature introduces risk into IT project deadlines. The best way to deal with it is to establish firm cutoffs for app development and enhancement cycles that everyone agrees to.

3: Lack of tool integration

Everyone talks about cloud, mobile computing, and the blurring of lines between computing platforms. But vendors of infrastructure software don't necessarily make managing across a diverse environment easier. Each vendor wants you to use its own toolset for management, and it isn't always clear which tools are subordinate to other software infrastructure management tools.  Consequently, it becomes difficult to fit everything into an "uber" infrastructure solution where you really can see everything through a single pane of glass. The best thing for IT to do is to require prospective tool vendors to show what application programming interfaces (APIs) they have that work with other management software. The APIs can be tested with other software in a proof of concept (POC) before buying. Finally, avoid the use of homegrown tools that don't readily interface with anything on the market.

4: Platform loyalty

IT's strength is its technical know-how. This know-how is accumulated over the years and becomes a career calling card for most IT professionals. Unsurprisingly, the sledding can get rough when someone who has worked on say, UNIX, for 20 or 30 years, is told to move to a Linux environment.

One way to ease the transition (if it is necessary) is to introduce these individuals to the new platform and provide the training and support they need for the crossover. If they're adamantly opposed to the change, there might be an opportunity for them to move into a maintenance role for systems that will continue to run on the old platform. If you can't provide that role, as a last resort you might have to encourage them to seek employment elsewhere -- in a shop that continues to use the platform they want to work on. In all cases, it is best to address these platform loyalty cases immediately and upfront, before resentment (and even lack of cooperation in projects) begins to set in.

5: Poor project management

Despite new project management techniques and tools, project management remains a weak area in IT. There are several reasons for it: a failure to cross-communicate across the project; the failure of project managers to "walk around" and really check out first-hand the status of work (besides just seeing the updates on a project tracking chart); and a breakdown of communications between the IT and the end user sides of the project team.

The best way to ensure great results in projects is to make projects smaller (and therefore more manageable), to encourage (and enforce) open communications, and to use collaborative project management tools that are now available in the market. It is equally important to perform post mortems of all project work -- to learn what went right and what could have been done better on each project -- and to take that knowledge into future projects.

6: Lack of documentation

Documentation isn't stressed in IT, which makes it a weak link in most IT work. No wonder most IT departments report that upward of 50 percent of their time is consumed in app maintenance. Less time would be spent in maintenance if documentation of what the original app was doing (along with history of maintenance already performed) had been done. Two ways to combat this are the adoption of new app development software that automatically documents work and a build-in of project time for app documentation and QA of the doc.

7: Poor data quality

The best technology in the world isn't going to change duplicate customer records with misspelled addresses or incomplete phone numbers. For data already on record, data deduplication can be used to ferret out duplicate records before they are stored or archived to disk. For new data, better field edits in applications can improve the quality of data that is being entered into data repositories.

8: Jargon

IT (like other technical disciplines) can become so comfortable using acronyms and jargon that it doesn't realize that it is using these terms with business users who might not understand them. This can generate communications breakdowns or even intimidation in relationships. IT can avoid this by stressing (and if necessary, training) IT staffers who work with end users to avoid these specialized terms and to stick with plain English.

9: Unrealistic deadlines

The pace of business is relentless and quick. As usual, IT gets pushed into accepting project deadlines that are too aggressive for the work that needs to be done. When this happens, IT delivers incomplete projects that are missing key pieces that subsequent enhancement cycles must handle. This is okay if the business is in total agreement with the approach. (In fact, it has worked very well in some areas, such as marketing.) However, if there is a governance/security issue, or if the app is required to be both complete and thoroughly tested, it is IT's responsibility to tell business management what the effort will take, how long it will take, and what the risks are if the effort is not undertaken.

10: Lack of people skills

IT continues to come up short in soft skill areas. CIOs should recognize this by budgeting for and providing people skills training to key IT contributors -- and they should up the ante by soliciting feedback from end users on the quality of IT interpersonal communications.

Other sand traps?

What issues have been a problem for you during your IT career? Share your experiences and advice with other TechRepublic members.

Automatically sign up for TechRepublic's 10 Things newsletter!

About

Mary E. Shacklett is president of Transworld Data, a technology research and market development firm. Prior to founding the company, Mary was Senior Vice President of Marketing and Technology at TCCU, Inc., a financial services firm; Vice President o...

23 comments
matt.woods
matt.woods

It is hard not to sound patronising about this, but sometimes the developer knows best. Users, contract managers or project managers may see a feature they do not like while the project is being implemented and get very focused on it. My team often encounter this, we may get a request that will save the user an hour or two during the implementation phase but we know it will be barely relevant to the ongoing project. If we succumb to pressure then we will only spend our time in exchange for the users time and end up with an unnecessary feature that requires ongoing maintenance for little benefit. Negotiating your way out of these situations is also time consuming, but I find it is always worthwhile because it helps both sides understand each other. Often it is necessary the user overcomes the difficulty themselves, because it involves them getting to grips with the logic of the system. Of course sometimes (not often) you might realise that the customer was right about the feature all along.

EJC05262
EJC05262

If the change requires a significant amount of behavioral difference and there is no general recognition that the change is required, the problem of installing that change grows exponentially. Moving from Lotus 1-2-3 to Excel was bad enough and that had some perceived value. But if management has decided to switch (tomorrow or even next month) to/from Outlook and IBM(Lotus) Notes the entire IT staff will want to go to lunch and stay there. Adaptation will be painful and aggravating unless there is a lengthy and expensive orientation and training program accompanying a detailed migration plan.

larrythethird
larrythethird

IT people forget that their only purpose is to keep everyone else working. Nothing more and definitely nothing less.

scotth
scotth

When Users would complain about moving to a new version of an application, I would tell them, "If you're an expert on an application, you're using an old version."

spencemeister
spencemeister

My BA team spent months discussing the queue of outstanding defects and the design limitations of a current business system. Then we created a new design that was elegant, flexible and offered opportunities for growth that had not even been considered before. We were excited at the possibilities as we imagined new customer configurations that had never been feasible before. It was an orgy of abstract thought and we were giddy with anticipation as we prepared the presentation of our new design. We fully expected lavish accolades and were already basking in the brilliance of our creativity. Our presentation was an unmitigated failure. The business didn't understand the value of the new design. The didn't understand it. It was too radical and complicated. They couldn't grasp how the design took care of the majority of the outstanding defects automatically. We were forced to fall back to the old design and just "fix the bugs." Our initial reaction was that they were all just too short-sighted to see the value in our solution, but we made some critical errors in our presentation. 1) We forgot that Operations people think more concretely than abstractly 2) What is intuitively obvious to one person is not necessarily so to anyone else. 3) It took us months to get to our design by going through a process of problem analysis, brainstorming alternatives, and solution development. We neglected to bring them through that process. 4) We didn't tell compelling stories while explaining our diagrams. In short, what we had here was a failure to communicate. We should have met our audience where they were and told them concrete stories that made sense to them in the here and now. Instead, we talked at them from where WE were. We made a presentation of abstract concepts that made us look like "those crazy tech people."

hauskins
hauskins

I think one of the biggest sand traps is to promise results that exceed the budget resources this would include staff and materials. There have been many cases where I have faced a situation of 'you have to deliver this for this amount of money', only to find out down the road that you are 20% short in budget.

hauskins
hauskins

UNIX to Linux or MacOS, that would be fairly easy. UNIX to Windows Server that would be a lot more challenging.

peter.heinicke
peter.heinicke

I have often found that there can be a culture of underestimating project duration. This is because less experienced programmers want to be seen as sharp and able to jump tall buildings in a single bound, so coding an operating system in a week, no problem, right? This tends to be a self perpetuating problem until somebody pretty senior catches everybody short by actually tracking the estimates and the actual results. (including any scope changes). Peter Heinicke http://www.pcmethods.com

EJC05262
EJC05262

1. I've spent a career interpreting between bureaucrat, accounting, medical, and programming. These worlds are separated by a common language that leads to misunderstandings and misdirected efforts. Every time we gave the client exactly what was asked for without clarifying what was requested in clear. logical and specific terms we had to do it again. Sometimes we did this on purpose to show the new user that our questions had value and he should pay attention. 2. As a dinosaur I remember training issues like not hitting enter(return) at the end of a typed line and explaining the difference between copy and move. Those early stories of waving a mouse over screen or thinking it was a foot pedal really happened. The more familiar one is with a topic, the more one has to think about the basics and how to train it. Early day example: This is called a mouse.; it causes this indicator to move; the indicator is called a cursor. The screen it moves on can be referred to as a desktop. When I say move the cursor on the desktop I mean on the screen, not your actual desk. And so on....

yattwood
yattwood

Companies are enamored of outsourcing - outsourced data centers, application development, what have you. So, applications (especially large ones such as ERP) are often done offshore, by the integration partner's outsourced staff until produciton - then it's "thrown over the fence" (often with very little documentation or handover) to the remaining in-house IT staff, who have to figure out how to support an application they had no input or contact with - it would be BETTER for the IN-HOUSE people to do NEW applications and give MAINTENANCE to the OUTSOURCERS

heyning
heyning

You mention 10 points. But do not underestimate number 11: lach of BUSINESS knowledge! Know your customer and his/her business/environment! Kees Heyning The Netherlands

EJC05262
EJC05262

If there is a prioritized list of tasks that is constantly being assessed and re-ordered there is a danger of new tasks trumping old and the items in slots 6 and above stagnate as new "more important" tasks replace 1,2 and 3 as they are accomplished - especially if (a) the new request comes from someone powerfully influential and/or (b) the new tasks are perceived to be easier than the older ones.

judi.doyle
judi.doyle

Here is a big one: Frequently representatives of the "business" side of the business fail to define and communicate meaningful business priorities for the use of limited IT resources. (Important point: Designating EVERYTHING as the "Top Priority" = Failure to Prioritize.) Lacking information about what the business priorities really are, IT staff define their own, which may or may not be aligned with the business's true strategic goals. If IT picks the wrong things to work on, IT will get blamed, but, by itself, IT cannot fix the problem.

rupniksc
rupniksc

IT asset management is focused on getting the most value from an organization's IT assets. This is accomplished by people with soft skills that can bridge the gap between IT and the business. The IT asset manager is also focused on managing the ITAM program which span the entire organization, instead of just the IT department. Managing IT from a business AND technology perspective as IT asset managers do increases the ROI and lower the TCO of these assets.

geek49203
geek49203

I think that IT management in general is always an issue. Sometimes we get someone who has a background in actually managing something, but is the quintessential "Etch a Sketch" boss The other times get an alpha geek who can't delegate and isn't organized and isn't willing to use "management speak" to communicate to others in management meetings. Project management does have its own special quirks, but it's basically the same -- either we get someone who doesn't understand the technologies involved, but has a plan that is done in excruciating (micro-managing) detail, or we get a glorified secretary whose only job is to dunn techs when they don't get some meaningless minor task done (or worse yet, keeps asking us about it as if we didn't have it done weeks ago).

drew247
drew247

While their existence seems to be fading somewhat, there are still quite a few business operators who resent the necessity of technology in relation to operating their business. It usually steams from a lack of understanding but manifests in sometimes hostile budgetary discussions. Having to explain to a small to medium business that their system requires maintenance, upgrades and/or lacks a necessary process can result in the death of the messenger.

RMSx32767
RMSx32767

leads to frequent claims of, and complaints about, uncooperative, and/or unhelpful, users.

tbmay
tbmay

Given Linux is is a Unix clone, I doubt you're going to get too much pushback there. Windows to Linux would have been a better point.

yawningdogge
yawningdogge

Unix to Linux migration is the best example you could think of to illustrate how hard it is to get people to accept new stuff?

ozindfw
ozindfw

It is patronizing and arrogant.

The number of cases of applications that are optimized for developer efficiency at the expense of customer efficiency is simply staggering.  Likewise, the number of cases I find where customers keep a spreadsheet or paper record to work around a system is simply shocking.  Heck, the number of applications that have to be driven with a notepad (paper or electronic) is just nuts.  How many times have you seen the free form notes field in an application become a defacto data field?  While this is usually attributed to lack of understanding and training, it's more often than not a lack of understanding and training on the part of the developer than the user.

The fact is that there are whiners on both sides.  A bigger problem is real communication of needs.  It's common for customers to express a want that is caused by a valid need, but that does not effectively identify the need to a developer.  It's equally common for developers to dismiss the want because they see no need even though they do not understand one that is clearly stated by a user.   

I make a substantial portion of my living fixing these.

Owen Glendower
Owen Glendower

that's exactly the right thing to say. Innovation for the sake of innovation, right? "But the new version has a lot of new features!" Does the user need them? More importantly, does the user KNOW that he needs them? You might consider finding out some things which the user needs to do but CAN'T do with the old application. Then show him that he CAN do these things with the new application. Perhaps he'll become an evangelist instead of a naysayer.

013gonzo
013gonzo

Try to start ZIM relation database on Linux. It work perfectly on Unix (from Zenix) and can not run on any platform Linux. Versions of ZIM that is running on Linux is totaly incompatible with 3.11 that is used on Unix.

Cicuta2011
Cicuta2011

I don't understand why people think Linux is NOT a UNIX platforms; all you have to do is look at it's structure and commands to see that it is one of the UNIX platforms flavors. Like all UNIX platforms, Linux has it's own commands but still it was derived from AT&T UNIX. Being Linux a very acceptable patform now days, still it lacks some of the utilities which, as an example, Solaris and AIX offer. I believe that being Linux a public domain platforms contributes to its popularity.