General discussion

Locked

Blogging IT One Word at a Time

By Bill Elmore ·
Tags: Off Topic
blog root

This conversation is currently closed to new comments.

65 total posts (Page 2 of 7)   Prev   01 | 02 | 03 | 04 | 05   Next
Thread display: Collapse - | Expand +

All Comments

Collapse -

Take Advantage of Project Pre-Analysis Opportunities

by Bill Elmore In reply to Blogging IT One Word at a ...

<p class="MsoNormal">I arrived at the office just in time for an unusually early
eight o?clock meeting.  As if that wasn?t
enough to erase the happy feelings I had when I first awoke, the meeting was to
discuss a project which hadn?t been approved for a system not yet purchased.  Besides the vendor, there were ?happy?
representatives from most of our IT departments ? Client/Server, Networking,
Database, Interface and local hospital IT staff.  The purpose of the meeting was to discuss the
feasibility of a new system before purchasing it.  The hang-up for most attendees, other than
the early start time, was they perceived the meeting as a waste of time.  Lost was the idea that we were called to
perform pre-analysis work, and not to fix something.  Performing project pre-analysis is a luxury
most IT pros don?t get to participate in, but should take full advantage of
when presented with the opportunity.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">The process usually works something like this.  Sales and marketing people peddle an
application towards directors and department managers, not IT staff.  The managers get sold on the benefits such as
increased staff efficiency and cost savings, and, ultimately, the system is purchased.  It is then handed to IT to implement and make
work in the existing environment.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">Back to project pre-analysis.  This represents the perfect time to request
more detailed information from the vendor, other than the one page data sheet
posted on their web site.  Many times the
sales person can give the contact information for one of their installation engineers
or technical support specialists.  A
single one-on-one phone conversation can often answer questions about the
architecture of the system, recommended hardware configurations, whether it is
supported and certified to run in a thin client environment, or if any
components are a good candidate for virtualization, etc.  An entire book could be written on what to
look for and what questions to ask during the pre-analysis phase.  But the important point to remember is to be
as thorough as possible.  Once
expectations are set with your customers (i.e., end users) and the system is
purchased, it?s nearly impossible to stop mid-implementation and proclaim that
it just won?t work.  Enough negative
indicators may be identified during pre-analysis to justify not purchasing the
system.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">One additional strategy I find useful is calling the customer
technical support line.  This can reveal uncensored
candor about common customer complaints and issues.  For example, they might reveal that printing
is always a problem because printers are defined per user using .ini files where
form margins are manually set.  Or you
could discover the system requires quarterly updates, which translates into a
30 ? 60 minute time commitment per server and each fat client, and, oh yeah, it
needs to be completed after hours.  Okay,
I slid in a couple of real examples, but they well illustrate my point about
the kind of information which can be gleaned from calling tech support prior to
giving the green flag for a system acquisition. 
It also can be an indicator to how promptly you?re able to speak to a
live person when needed, or if the norm is to leave a message and wait for a
call back.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">So, the eight o?clock meeting scheduled with the good
intention of identifying potential implementation pitfalls never got on
track.  The ninety minutes were largely
spent arguing over why we shouldn?t be discussing this project when another
major project is on the horizon.  It is a
shame more analysis and brainstorming didn?t get accomplished with so many IT
team representatives in one place.  It is
not often that all the pieces are together for collaboration and analysis from
different areas of expertise.  An
opportunity like that should not be squandered. 
A little research up-front today can pay huge dividends for future
projects tomorrow.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">Feedback is welcome as always.  Let me know if you have developed a good
system for conducting project pre-analysis, or if you face similar resistance to
the process in your workplace.</p>

<p class="MsoNormal"></p>

Collapse -

Take Advantage of Project Pre-Analysis Opportunities

by barryc In reply to Take Advantage of Project ...

<p>Would you as an IT pro, as the article puts it, read and accept as useful a white paper from a vendor that identifed issues relating to implementing their product? Assume that it covers the obvious factors as mention in the article and perhaps points out some other factors, pro and con to consider?</p>
<p>How about it it was a comparison peice - talking about advantages of the vendor's product as compared to a competitor's? It you would tend to be adverse to a competitive piece, how about if the paper seemed reasonably fair and impartial. (Reasonable means that it says nice things about the competition but still presumes that the vendor's product is a better choice.)</p>
<p>Self interest is involved here - my company produces the kinds of papers I'm asking about. My goal in the question is to hear what the people who read them have to say and would want to learn.</p>

Collapse -

Take Advantage of Project Pre-Analysis Opportunities

by cdyer In reply to Take Advantage of Project ...

I totally agree.  My boss has taught us the value of such pre-analysis and we now expect input from all attendees to arrive a our consensus.  It has saved us countless hours and headaches in implementation later, and it has earned us respect from our (in-house) customers that we have our stuff together whenever something new is considered.

Collapse -

Learning to Control Data Access

by Bill Elmore In reply to Blogging IT One Word at a ...

<p class="MsoNormal">Things just continue to change. Actually, IT is <i>always</i> changing and always will.
That is part of the fascination and draw for me, and one of the main
reasons I chose this field. Right now,
you?re probably wishing I would pick a topic and run with it; and so I
will. </p>


<p class="MsoNormal">For the past several years, I?ve been watching varying
levels of user access to electronic data become further and further
scrutinized. The scrutiny comes from IT
managers and, ultimately, CIOs who are responsible for ensuring only those who
need access to sensitive private data have access to it. The direction and push to control who needs
access to what and why, comes from internal and external audits to maintain
compliance with regulatory laws such as Sarbanes-Oxley (SOX) and HIPAA. </p>


<p class="MsoNormal">Controlling user access to electronic data means a lot of different
things to IT staff working in the trenches every day. It means setting up the proper security
controls when installing new systems, and not leaving the default Windows
permissions to shared folders. Leaving
the Everyone group with full access to a folder does not constitute a good
security plan. Setting up an Active
Directory Security Group for a new system and then adding only those users who
need to use the application as part of their job is a good start. If they don?t need Modify rights to the
directory, only give them Read rights.
These are common sense rules, but it?s amazing how many IT pros get lazy
and leave the default permissions as-is or don?t set up separate AD security groups.</p>


<p class="MsoNormal">Of course, even those users who do have a justified reason
for accessing a system can abuse their access and violate privacy laws. For instance, a healthcare employee may have
a job that requires occasional access to electronic medical records. Since access is pretty much all or nothing,
they may be tempted to peruse the records looking for patients they recognize
(e.g., friends or family members).
Without justifiable cause for accessing the records, this is a
major infraction and presumably grounds for termination. It is ITs responsibility to put safeguards in
place and to provide checks and balances for this kind of user behavior.</p>


<p class="MsoNormal">One such mechanism is to utilize Windows Group Policy to
enable object and directory access auditing.
This method is okay and may be the only means available of keeping an
audit trail for certain applications.
But more than likely, an application written within the last few years and
which stores sensitive data will have built-in capabilities for logging/auditing. Many times, power users working as system
administrators will get the responsibility of periodically reviewing these system
audit logs. Knowing who accessed what
and why they accessed it is the goal.</p>


<p class="MsoNormal">One area of user access control proving to be an issue where
I work is vendor access. Not access to
specific files or servers per se, but VPN account access. Our policy is for each vendor support person
accessing our network to have an individual VPN user account. The reality is one or two support reps
assisting with the implementation get accounts created in their name, and then
the credentials are stored in the vendor?s customer database for use by any
future support person to use. So access
logs aren?t accurate and we really don?t have any way of knowing exactly which
rep connected to the network after all. </p>


<p class="MsoNormal">But would compliance auditors give good marks to our company
for being able to say we require individual accounts for all vendor support
reps? Yes, but it is more of an empty
fulfillment of the requirements. For
larger vendors with many support reps working various shifts, it?s just not
viable to keep track of another company?s active employee roster. In this case, the more rational approach is
to require the vendor to sign a Service Level Agreement (SLA) specifying they
are responsible for logging each rep that works on an individual support
ticket, and they must be able to provide the access logs at the customer?s
request. This approach, while not
perfect, actually comes closer to accomplishing the goal ? knowing who accessed
a system which stores sensitive data.<br /><br />There are many other aspects and examples to controlling
access to electronic data. I?ve only
touched on a couple, but it all goes back to ensuring sensitive data is
accessible only by the people who need it to do their jobs. As always, let me know your comments and some
of the ways you control access to critical data.</p>

Collapse -

Learning to Control Data Access

by fultonwilcox In reply to Learning to Control Data ...

<p>Your comment that access to sensitive data is permitted on an "all or nothing" highlights a fundamental problem, because "need to know" is inherently situational to the job functions and specific assignments of the inquirer. Therefore, establishing user accounts, effective authentication and, perhaps, role definitions are all necessary steps forward, but are not sufficient for the "new world" of comprehensive data. The recognized objective should be to compartmentalize dynamically and on a very granular basis, even though that objective is a bit out of reach using today's capabilities.</p>
<p> </p>
<p>Fulton Wilcox</p>
<p>Colts Neck Solutions LLC</p>

Collapse -

Learning to Control Data Access

by Bill Elmore In reply to Learning to Control Data ...

Thanks for the comment.  What I meant by "all or nothing" was a user who has access to patient data within a clinical application typically has access to all of the patients.  This can mean a medical records employee or a nurse working in ER.  It's true, though, that many of the applications have granular security settings for restricting access to certain modules, such as Radiology images or lab test results.  So, in this way more distinctive application and data access can be restricted.<br /><br />-Bill E.

Collapse -

Learning to Control Data Access

by milal In reply to Learning to Control Data ...

<p><br />The medical records scenario you brought up is a situation that is very real in the medical world. I'm sure this happens often in financial, legal and other industries as well. Unfortunately, issues regarding controlling data access don't stop there. What about e-mail? How can a lawyer stop an intended recipient from forwarding private lawsuit information, or a doctor make sure that his patients' data stay in his nurse's inbox? Access rights issues are far and wide. Solutions are being developed, but obviously Microsoft's Private Folder didn't work. For e-mail, companies should at least be using encryption, and even better look into rights management - which specifically control e-mail and attachments after you hit "send". <a href="http://www.essentialsecurity.com/Documents/article9.htm">http://www.essentialsecurity.com/Documents/article9.htm</a></p>

Collapse -

Empowering the Users

by Bill Elmore In reply to Blogging IT One Word at a ...

<p class="MsoNormal">It seems that IT staffs are annually given more work to do
than they were the previous year; more new and complex projects to implement
while continuing to support an ever expanding list of yesterday?s systems.  The increase in work appears to be disproportionate
to the increase in new help hired.  Speaking
with friends in IT at other companies I discover the exact same scenario.  This is odd because I also know people
looking for work in IT, but who can?t seem to land a job despite their
substantial efforts.  So what is the
answer to getting more work done with less? 
More systems management utilities and appliances?  Server virtualization?  Robocopying ourselves?  No, I say it?s one word ? empowerment.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">Give power to the people, or users in this case.  No, I am not inebriated as I write this.  And yes, I?ve witnessed my fair share of dumb
user moments; even contributed on a couple of those occasions.  I?m not saying make your users local
administrators of their workstations and hand them the keys to the server room
so you can play golf.  Page me if I?m
needed, please.  </p>

<p class="MsoNormal"></p>

<p class="MsoNormal">What I am saying is identify and enlist the help of one or
two power users as you are implementing a new system; preferably two in case
one leaves the company.  You?d be
surprised how helpful a user serving as the system champion and front-line
support person can be.  Many times the
empowered person will end up being the user who stands to benefit the most from
the new system.  It?s in their best
interest for the system to be successful and remain in proper working
condition, and it frees IT staff to concentrate on rolling out new applications
and troubleshooting infrastructure level issues.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">What level of empowerment am I suggesting?  I am suggesting that a user serve as pseudo
system administrator for the day-to-day functions such as creating user
accounts within the application, resetting application level passwords, and
running applicable system maintenance tools as needed.  Basically, anything that can be done from
within the application and from the user?s PC should be fair game.  The key is to remove yourself from the daily
operation of the application, and empower a designated user to accomplish these
routine tasks. </p>

<p class="MsoNormal"></p>

<p class="MsoNormal">Defining role based system access levels is extremely
beneficial.  Many times, applications
will have granular security which is capable of hiding groups of functions not
needed by all users.  This level of
granularity should be managed by someone intimately familiar with the system that
can fulfill user access requests.  Functions
needed for system administration should only be accessible by the power user.  All other access to the system should be
predicated on what they need available to perform their jobs.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">Empowered users can serve as front-line support for other end
users, intercepting many requests before they reach your desk in the form of
support incidents.  In the days leading
up to a system go-live event or immediately after, go over documented steps to
resolve common issues and requests.  Is
the user unable to print because the printer is paused or out of paper?  Teach them to fix common problems and it not
only frees some of your time, but it also makes for happier users.  Their issues are resolved quicker because
they won?t need to wait for your schedule to become light enough to help
them.  </p>

<p class="MsoNormal"></p>

<p class="MsoNormal">Empowered users can prove extremely beneficial in
communication.  For instance, I have
found them to be very helpful with relaying system downtime intervals due to
server reboots, patch installations, etc. 
It is much easier to provide pertinent system information to one user
and have them disseminate that information to the other end users.  A power user can also provide details
(sometimes in the form of screenshots) about a reported problem which can prove
beneficial when troubleshooting and working with the vendor.</p>

<p class="MsoNormal"></p>

<p class="MsoNormal">Empowered users can accomplish many things, but most
importantly they can make your job easier. 
Don?t leave them out of your plans when rolling out that next
system.  And, as always, let me know your
thoughts and experiences related to this topic. 
</p>

Collapse -

Empowering the Users

by austamm In reply to Empowering the Users

I do agree strongly with the concept of empowering users. With the ever incresing solutions that need to be provided by IT personnel, one should not be stuck with some routine roles that could easily be assigned to super users. There is evidence of an increase in resource utilisation by users with because of this. I practice this.


Amimu

Collapse -

Empowering the Users

by The Old Man In reply to Empowering the Users

<p>While a crude example,  our folks never had to pump gas.  Now everyone does.</p>
<p>Another is the self check out line at the grocery store..</p>
<p>It's the only way to survive.  The key is finding out where to draw the line.</p>
<p> </p>
<p>Great Post!</p>
<p> </p>

Back to After Hours Forum
65 total posts (Page 2 of 7)   Prev   01 | 02 | 03 | 04 | 05   Next

Related Discussions

Related Forums