Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

The Boss's Fears.... 3

Status
Not open for further replies.

Jones007

Technical User
Jan 12, 2005
3
US
Hi,
Ok, here's the issue: the department I'm in has manual processes that obviously need automation. The boss has a few techies that he asks to help with automating.
And these techies put together programs and processes to meet his needs...whether they be small databases or full-blown web-based programs..THEN..after this great process is created.... the boss knocks down everything created because he fears "break-ins".. security (mind you.. most of these processes have little or no need for high security features) and so nothing ever comes to fruition. His fears of losing data are hindering any growth and improvement....
Any suggestions???

-Agent99

-Agent99
 
Have you tried asking up front what he would like to see in terms of security for a given project? I work in the Financial/Insurance industry and security is ALWAYS one of the up-front requirements that we get from the users when starting a new project.

Also, it might help if someone pointed out that if there were a fire or a flood, he'd loose all of his paper "data" and that data kept on a server can be backed up and sent off-site (securely, of course), preseving it from those types of hazards.

-Dell
 
I worked in the machine tool industry for a long time, now I'm working in the financial services industry.
Huge difference, security of info (financial, customer info, etc, etc) is vital.
As Dell pointed out, need to discuss security needs with mgr (and others?) so you have a starting point.
Let us know what happens!
Jay
 
Let's digest this a bit...

...the department I'm in has manual processes...

Implies you are one department within an organization. Is the organization large / small / structured / independent / partially unionized / not unionized??

If you are large enough to have departments, are you large enough to have an IT department? They are the ones responsible for security. If you have a highly structured departmentalized / controlled organization, then they would also be involved in your "automation". I suspect you have more autonamy / freedom than many of us.

...But why is IT not involved in the discussion of security, standards, etc.

...department ... has manual processes ... need automation. The boss has a few techies that he asks to help with automating...

Okay, first, the boss is resposnbile for his department which includes budget, policies, procedures and performance. Having said that, your boss seems to realize that he needs to or notices that other departments are ahead in terms of intergrating technology with the business. This is a step in the right direction.

THEN..after this great process is created ... the boss knocks down everything ... because ... security

Interesting. I have wonder why security was not apparently discussed near the beginning of the project.

When starting on a project such as this, you should perhaps include such things as...
- objectives and deliverables
- roles, assignments and ownership
- security
- backup, disaster recovery and redundancy plans

When this "process" was started, was it organized, or more "fluid" at the descreation of the "techies"? Were there status updates, etc?

...And is your boss more of a computer geek, a ludite or old fashion, young, middle aged, nearing retirement, been with your organization for a long time, or recent hire? And do you know who he plays golf with, or hangs out with after hours or during lunch who is "technical"?

...most of these processes have little or no need for high security features...fears of losing data...

I understand since most / all of the project was internal, hence no Internet access, security was not apparently a big concern. However, it is actually quite prudent that your boss is concerned about security, but since he has not factored in that the security issues are of lesser import, then you have to wonder what made him change his mind.

Is he basing this change in heart on experience, or on did some one or something influence him? Are you able to look at the decision from his perspective? Do you think his decision to back out of the automation was because he "chickened-out", or he lost confidence in deliverables, or something in between, or he is just a ludite to the extreme.

Lessons learned
It sounds like some of this work was fairly signficant. Otherwise you would not appear to be so upset. From the school of hard knocks, and as I try to teach my kids, regardless of huge or small a (school) project is, you need a plan. Since your plan deals with automation, the plan must include some / much of what I outlined above - objectives, ownership, security and disaster recovery.

Regardless of how simple or complicated, the plan does several things.
- It allows both parties to develop a more consistent set of expectations and a time table.
- It allows both parties to discuss issues in an objective way.
- It will allow the person who is taking the risk, your boss (the customer), to see areas of weakness or strength. "This is who is doing what" "This is how we are addressing security" or "Security is not too important because there is no access to the Internet" "This is how we make sure data is not lost" If all the concerns are answered and addressed, then it gives the cusotmer confidence in the work and the expected outcomes. If an issue, such as security, is not a concern, you still need to identify this and explain why.

(Hint: when it comes to money, security is ALWAYS an issue -- even if it is login, restricted rights, etc.)

Having said all this...
- I suspect the person who should have made "the plan" is management, i.e., your boss.
- You should leverage your IT department -- How do other departments handle this or that? What is the standard?
- You should leverage other departments. Get another "boss" or two to show how they handle various tasks that are similar to the ones done in your department. How much improvement did they expereince.
- You may still be able to salvage the project. Approach the boss, and ask to discuss the project. Then prepare documentation and leverage support from IT and other departments. Impart on the boss that change will come, eventually, and you want to make sure the change is an improvement in the way things are now done.
- REMEMBER, he is still the boss. He is accountable for the performance of the department. If he wants to tell 10 people to move 100 cannon balls to this location, not that location without using a fork lift, then it is his choice. It will be very frustrating for you and your coleagues -- I understand.

My past experiences...
I recall when my wife was responsible for providing technical support for a department / college at a university. The chair of the college was a real ludite. For example, IT infrastructure was laying fiber cable within 3 meters / 10 feet of a major building belonging to the college in question. She approached the chair and explained that this was an exceptional opportunity to save a significant amount of coin by allowing the infrastructure team to supply fiber to the building (it was an astounding amount of money to be saved -- less than 5,000 vs over 500,000) instead of doing it later. His comment was that his department should focus on doing their work instead of playing on computers. He refused to realize that the computer was to be the most significant tool in research, teaching, etc. My wife was extremely frustrated by this. Years, later the college was connected to the university network at 100's of times the cost (now well over a million) it would have been if they had taken advantage of opportunity my wife presented to them. But the decision was still that of the chair of the college.

Also, I have seen several projects in the millions of dollars fail, or encounter signficant and unecessary costs because the planners forgot the basics -- they were more involved with the "hype".

Good luck.

 
Two Words:

Offsite Backup

Run a tape backup daily. Once a week, take the tapes to an offsite location. LEARN how to restore files off the tape backup so, if data is lost, it can be restored quickly. (You don't want to learn how to do it at crunch time.)

With an uber-paranoid boss like that, someone in the office needs to learn about disaster recovery. It sounds like they're very, very unprepared.
 
Thank you all for your input. You gave a lot of good suggestions and issues to think about. I believe that the main issue is a matter of convincing him that security measures have been addressed and showing him that the data can be recovered easily. This is a department within a large corporation but he wants his own team to handle the information technology. It's not so much a matter of the team not addressing security/backup strategies or lack of planning.. this is about about convincing the boss who has great fear of "technology" that his data will be safe. He has more faith in paper at this point.
I think it will be a matter of showing him exactly how the tool works.. and if there can be changes made to the orig. data then there is some sort of indication that shows the change and if there is loss of data, that it can be recovered quickly. This is like telling him that it's okay to jump off this cliff because he has a parachute or a rope to keep him alive.


-Agent99
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top