CertCities.com -- The Ultimate Site for Certified IT Professionals
Visit CertCities.com Forums and Ost Your Mind Share share | bookmark | e-mail
  Microsoft®
  Cisco®
  Security
  Oracle®
  A+/Network+"
  Linux/Unix
  More Certs
  Newsletters
  Salary Surveys
  Forums
  News
  Exam Reviews
  Tips
  Columns
  Features
  PopQuiz
  RSS Feeds
  Press Releases
  Contributors
  About Us
  Search
 

Advanced Search
  Free Newsletter
  Sign-up for the #1 Weekly IT
Certification News
and Advice.
Subscribe to CertCities.com Free Weekly E-mail Newsletter
CertCities.com

See What's New on
Redmondmag.com!

Cover Story: IE8: Behind the 8 Ball

Tech-Ed: Let's (Third) Party!

A Secure Leap into the Cloud

Windows Mobile's New Moves

SQL Speed Secrets


CertCities.com
Let us know what you
think! E-mail us at:



 
 
...Home ... Editorial ... Columns ..Column Story Saturday: April 5, 2014


 Kohut's Corner  
Kevin Kohut
Kevin Kohut


 Yeah, But We're Supposed To Do it THAT Way...
When it comes to fighting idiotic business processes, a little communication (and some actual concern) can go a long way.
by Kevin Kohut  
9/18/2002 -- I was talking with my buddy Jon the other day. He's a Web developer, among other things, and was sharing an experience with me about a dot com he used to work for. This particular organization was paying him a good hourly rate (Oh, for the good old days before the dot com crash!) to develop various Web elements for them. But for the first week that he was there, he didn't get a whole lot accomplished.

Oh, he had a great machine to work on, a big monitor, even a nice office chair. What he didn't have was administrative access to his local system. The IT department had to iterate through several steps to address this issue: First, someone needed to meet Jon at his desk to discuss the problem; then, paperwork had to be signed and processed; finally, the very simple task of adding Jon's user account to his machine's local administrators group was completed. Something that shouldn't have even happened in the first place took over a week to "fix."

Jon's problem was not due to technical issues. I'm sure that all parties involved knew all along how to add a domain account to a local administrators group. No, the issue here was about business processes (or, more accurately, the lack thereof). Why wasn't Jon's PC set up correctly from the outset? Why did it take three IT help desk tickets and two different managers' signatures to fix the problem? Two obvious questions, begging a third: So who is supposed to implement the business processes required to address this issue (or any other issue, for that matter)?

This is where I may appear to talk out of both sides of my mouth. On the one hand, I sympathize with IT professionals who desperately want to make the Jons of the world happy, but are constrained by the current "system." On the other hand, I have to ask why IT pros aren't more proactive in trying to change that system. What follows are some suggestions to folks in either group, culled from both my own and others' experiences.

Document What You Do
We IT types are notorious for not documenting things. If we were students in one of my wife's algebra classes we'd all probably fail for not showing our work. The first step to establishing a business process is to define it. And in order to properly define it one must document it.

I'm not talking about keeping copious notes, or detailing every last task you do minute by minute. But creating a high-level check list or a simple flow chart of what it takes to accomplish some aspect of your work can be very helpful. The idea is to develop something that will demonstrate the consistency of the process ("Every time I've set up a new system for a developer I've had to do these six things…"), as well as articulate how to actually do it.

But please, don't go running to your manager with a purchase requisition for some new software tool to help you with your documentation. Yes, there are some very nice tools out there, and yes, they can be of great help, but stick with Word, Excel, Outlook or even the lowly, non-tech solution of paper and pencil.

Give a Rip About What "They" Do
"They," in this case, referring to the people you support. I've got to believe that had those IT folks at the dot com where Jon worked truly appreciated the work that their Web developers needed to do, they would've addressed the local administrator issue much sooner. In the sales and marketing world they call this, "feeling your customer's pain."

As IT professionals, we need to feel our customer's pain -- not just react to it. Take the time to learn a little bit about what the various people in your organization actually do. Ask them how they use technology, and what aspects of it are especially important to them. Go to lunch every so often with people from your company who don't know what the standard subnet mask is for a given IP address, or the difference between SDRAM and DDR (assuming, of course, that all the IT pros in your organization do know this stuff!).

Give a Rip About What "They" Do, Too
In this case, "they" refers to the specific individuals responsible for setting business and IT policies. It has been my experience that very few processes and procedures were deliberately constructed so as to be convoluted and counterproductive. Rather, they are typically a result of someone trying to stay within existing guidelines (or, the interpretation of those guidelines).

Take Jon's situation, for example. I doubt a bunch of IT managers gathered 'round the old conference table and decided, "Hey, let's make the process of setting up a new system for a developer take a week to complete, and let's also be sure that it takes three help desk tickets!" More likely, there were several different policies in place, each of which serving a valid need, and in and of itself, quite reasonable.

The IT pros at Jon's company could have analyzed the reasons behind the current process, and perhaps recognized that management wasn't putting the screws to developers. By understanding the WHY, they may have been able to improve the HOW.

So, You Wanna Change the World?
Maybe not! If you're like a lot of IT professionals, you're not interested in company politics or which department has the best mission statement. You just want to ply your trade, make a few bucks and not have to reboot Windows-based servers (well, two out of three ain't bad!). But when we let red tape stop us from doing our jobs, that makes all IT professionals look bad. Buck up, suck it in, and fight a little -- you might be surprised at what you can achieve.

What business policies at your work have confounded all logic? What's the best way to change the system from the inside? Post your comments below!


Kevin Kohut has been involved with information technology in some form or another for over 18 years, and has a strong business management background as well. As a computer consultant Kevin has helped both small businesses and large corporations realize the benefits of applying technology to their business needs.

 


More articles by Kevin Kohut:

-- advertisement --


There are 4 CertCities.com user Comments for “Yeah, But We're Supposed To Do it THAT Way...”
Page 1 of 1
9/18/02: nyert says: More than communications, you need to educate. Most of the problematic company procedures are created by people who don't understand (and don't have the background to understand) IT functions and processes. They probably won't realize that there even is a problem, so it's up to IT to bring them up to speed. They don't need the details about IP addressing or memory types, but they do need to know how IT feels are the best ways for employees to interact with the LAN / WAN. For this article's example, Human Resources and / or hiring managers need to know to inform IT about the role new employees will play. Then IT needs to propose how to accomodate those new employee roles (in a manner that is compatible with IT's operations). Hopefully one short meeting with the parties involved will get quick results. For problem procedures that recur, we identify the problems and possible solutions. Then, we invite effected managers to a short training session. We explain typical employee LAN / WAN interactions or needs and how they effect IT's operations. For the article's example, we'd explain what kind of access the developer would need to which systems, how we can grant access, how we corral them to only the area they need access to, and how the managers can help us accomplish all this. It helps break down departmental barriers too!
9/25/02: Trapper John MD says: I think companies should require there employees to watch the full first and second season of M*A*S*H. Then they should allow the IT department to talk to them.
10/3/02: Major Frank Burns M.D. says: I think COMPTIA should release a M*A*S*H+ to show foundation level knowledge of the folks at the 4077. Oh Margeret
11/27/02: Nothin' changes says: That will never change and the only thing IT people can really do to take "action" is to hit happy hour for a few cold ones.
Your comment about: “Yeah, But We're Supposed To Do it THAT Way...”
Name: (optional)
Location: (optional)
E-mail Address: (optional)
Comment:
   

-- advertisement (story continued below) --

top