"Rogue IT" 11

[vbainchicago]

I've recently found myself in an interesting situation and wanted to get "unbiased IT" opinions. Here's where I'm at:

My "job is not IT related. I've been in purchasing for 9+ years with two different companies. My passion has always been "IT" related - database design, SEO, building websites, building and troubleshooting PC's, networking, etc. I've been working on IT projects on my own for a little over 10 years. I've never had any formal training - everything I know I've taught myself through books, trail and error, and forums like this one. 3 years ago I even started my own consulting company on the side and have been doing fairly well.

I've been with my current company for a little over 4 years. When I started, the "systems" in my department were a joke. Nothing was automated, and no one had any idea how to use even basic functions in MS Office applications. The person who trained me actually told me "Excel is just like Word only it has boxes to help your keep things organized".

In order to do my job more effectively, I designed databases in MS Access. When my co-workers saw that I could get done in 5 minutes what took them 5 hours, they took notice. My systems grew from a single user (me) system to an integrated system that over 25 people use on a daily basis. Some newer employees have even been trained on my software since the day they started, and couldn't do their job effectively if you took my systems out of the picture.

I was recently called into a meeting with my boss (he's pc illiterate) and two of the head IT people from our company. It's a decent size company (over 500 people) so I had never even met the IT people before. I was informed that the work I've done over the last 4 years is what they deem "Rogue IT", and that I was to cease any further development on any system. I was also supposed to hand over all my passwords (I implemented security in my db to prevent tampering) and if I hadn't already, thoroughly document the db design and functionality and hand that over as well. As of today, I've just continued to ignore the requests.

Portions of the db were developed at work, and my boss approved the time spent working on them. My boss has actually requested database modifications and additions over the years. I did a lot of the db design and modifications outside of work on my own PC and on my own time as well.

The justification is that if I leave, no one could support the system. There's no "Access expert" in our IT group. They have requested that I train one of the IT people on Access and walk them through my entire database. Of course, I have to do this in addition to my regular job, as no one will cover my regular responsibilities while I'm "training" my IT department.

What do you think? How would you handle this situation?


VBAinChicago

http://www.jjscomputing.com

For Fun -

http://www.321google.com

 

[avjoshi]

VBAinChicago

I own the offsite server - it's at my house.

The important files on my home server are backed up nightly to another server at a friends house. ???

Is your friend working for the same company? You can not and I repeat can not treat it as your own property. The software belongs to your company. You could be serious breach of your contract and/or company policy.




Anand

 

[vbainchicago]

No, he doesn't work at the same company.

Are you saying sending/taking/bringing a file home, and in some cases working on it there, is a potential violation of policy?

What if I start something at home - an excel spreadsheet for example - then bring it to work on a CD? Is it mine, or does it belong to the company I work for? I've checked, and this specific issue is not addressed in our corporate policy handbook or the non-disclosure agreement I signed when I started employment.

VBAinChicago

http://www.jjscomputing.com

For Fun -

http://www.321google.com

 

[jrbarnett]

vbainchicago

While it is admirable that you have such off site data backup procedures in place, avjoshi and other members are correct: Unless there is data encryption to stop your friend getting access to this data held on the server at his house, you are almost certainly violating data protection laws in doing this, and if the data are confidential to the employer or their clients, which 99% of the time they will be, they could potentially sue you.

John

 

[Dollie]

This situation sounds like it's going to go from bad to worse. I would think that if I were hired for a job and I could develop a better way to do it, I would not only be happy to do the development, but to train someone else on it using the "hit by a bus" theory. Always remember, no one is irreplacable.

To have an offsite server that I am loading my work and my company's data to, then refusing to share my development and not wanting to train anyone could be considered theft.

I do not see where the intial poster could even consider not training anyone. I totally understand why the IT dept has a problem with this person.

 

[Dimandja]

This situation sounds like it's going to go from bad to worse.

What else resides on this "backup" system? Rogue Kazaa files?

Dimandja

 

[Dollie]

Being unable to amend my post, I'd like to add a few comments to VBAinChicago.

An excel spreadsheet is not the same thing as a 25 table database with all my company's data contained in it. It's just not the same thing and is a bad comparison to use.

As an aside, Access is becoming outdated. It's not unusual for companies that don't have Access applications to not have someone trained in it. We use no Access applications, and none of us here could operate it properly if our life depended on it.

If you have exported the companies data along with the application you developed without their knowledge, it's a breech of contract and can be considered prosecutable theft. I would think that anything you do in relation to your job that includes their information belongs to them, not you.

Not wanting to train IT on something they had no part of programming would definitely appear to be rogue to me, and would be met with a comparable attitude, especially when it deals with proprietary information.

I believe that with all the ownership issues you have, you have a much larger problem on your hands. Ego has no place in ethics.

 

[sleipnir214]

vbainchicago:
You signed an NDA, yet you transmit corporate data to two corporate-external computers, one of which is controlled by a person not contractually obligated to protect your company's data?

This scenario gets worse the more I hear about it, and the more convinced I become that your company's IT department's takeover of the company is long, long overdue.

For your sake, I hope you have taken every step to keep that data protected. If something goes wrong and your company's data gets published somewhere, you're going to find yourself in a nine line bind.


Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[strongm]

>Is it mine, or does it belong to the company I work for?
>not addressed in our corporate policy handbook

Doesn't need to be. At a bare minimum this is covered by (in the US) the work-for-hire rules.

> You could be serious breach of your contract

Quite - but there's a lot more to it than that. For example, the company could be in breach of regulatory compliance as a result of this. Disaster Recovery and Business Continuity Management could be adversely affected. Security could be significantly compromised.

 

[strongm]

Well, looks like we're developing a consensus here...

 

[CajunCenturion]

And if this is a publicly traded company, and this data can in any way be used in the making of buy/sell decisions, you could find the SEC knocking on your door for providing inside information.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[vbainchicago]

The "front end" of the db that I back up off site doesn't contain any data - all of the data is left on the servers at work. The front end only has forms, queries, code, etc. NO DATA. The company's data never leaves the building.

Somewhere along the lines I either omitted something, or it was misinterpreted.

I don't have any problem providing documentation, passwords, etc. That's fine. I would hate for my coworkers to be in a bind if I was "hit by a bus". The only sore spot was the not being able to contribute to the continued development…which just in the last day has changed. I've been given authorization to make all the changes I desire - as long as the documentation is kept up-to-date.

Dimandja, I appreciate the feedback and help in this forum, but the Kazaa comment doesn't really add any value to the discussion. Dollie, I appreciate some of your points as well, but will respectfully disagree with the "ego" comment. My biggest concern was that by not being able to change/modify the db, I would not be able to perform my primary job functions as efficiently. It's not about ego - it's about efficiency. I may have not made that clear in previous posts.

I followed some of the advice in this forum, and it looks like everything is working out to everyone's satisfaction. I won't be handcuffed in terms of making modifications, and the IT group will have everything they need to pick up the pieces in case of emergency. They also decided not to push the training issue, as they have determined they would prefer to devote their resources elsewhere at this time. They're even considering having me design some small apps for other areas of the company that will eliminate some manual processes. Nothing fancy or mission critical, but still, it should be fun.

Thanks to everyone who offered their on topic opinions - you've all been a great help.


VBAinChicago

http://www.jjscomputing.com

For Fun -

http://www.321google.com

 

[DrJavaJoe]

Well then, the cup is half full, glad to here it.

"Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'."

 

[Dimandja]

vbainchicago,

Congratulations! Everything will work out since you are so dedicated - and you have demonstrated that you can communicate effectively and can work with a disparate group of people (as in this forum). Sorry for my feeble attempt at humor.

Dimandja

 

[vbainchicago]

No problem, and thanks for your help. Sometime it's difficult to pick on humor when it's written, but that's ok. Bottom line is everything worked out, and this is still the best tech forum out there.

VBAinChicago

http://www.jjscomputing.com

For Fun -

http://www.321google.com

 

[SemperFiDownUnda]

I agree with Cajun about how the front end should be backed up on the companies server.

One note to people is that you should carefully read and understand what is posted before attacking, and that is what I saw happen, others. Maybe it was because I have these posts spoken to me, via Text-to-Speech, that it was 100% clear that vbainchicago did not expose any data to sources outside the company when he said

The app is split - "front end" holds the forms/code/queries, etc.

The backend only holds the tables and it's on a file server that our group has access to. The IT department backs this server up each night.

The primary .mdb front end resides on my local machine. I wrote a script that copies the front end to an offsite web server each night, then sends me an e-mail confirming that the transfer/backup was successful.

While I don't agree with the backup of the front end db, as it is it cleaver but overly complicated.

If your company is set up properly it has disaster recover plans and off site backup.

The issue here is what happens in a real disaster? Lets say a natural disaster hits. There is a good chance that if the company's building gets wiped out that your house and your friends house could be wiped out to. Even if they are not just the loss of electricty kills your back up and recovery. Disaster recovery plans over come this buy a number of ways. They normally pick a location that is sufficiently far away from the main site as to be not effected by the disaster. The site probably has some type of emergency power. Plans and proceedures to get a functioning network with the latest data from corporate backups are in place. Then your team comes in and oh no....Joe has my front end but I can't get to it and your dept, that is already stressed about the disaster, job becomes even harder because your system isn't available.

Well anyway I'm glad things are working out for you. This could be a great move forward for you as long as you don't mind the procedures that while/should be inplace that, at times, may seem to hinder your progress.



Hope I've been helpful,
Wayne Francis

If you want to get the best response to a question, please check out FAQ222-2244 first

 

[gpastorelli]

I had a very similar experience with my previous job. I was a member of the Operations dept. yet my position was technical services rep. I never really did much technical service, pretty much setup classrooms and filled soda coolers (yup real fun, lol).

Well anyways, during a meeting they were arguing over there current asset tracking solution, which was a fancy excel spreadsheet. I had been working on something similar for a few weeks and brought it up. I got the go ahead to finish it. Had I finished it according to the way I set it up it would've been done in 2 weeks. Long story short, it turns into a 5 month project, they complain it's taking too long and I finally finish it.

During the whole project they promises a bonus and a promotion (to IT dept.). Well none of that happens and I quit and I had to hand over documentation and everything to them. Well everything that belonged to them. They wanted complete training on the app both for users and support. I gave them none of it, not because I wanted to be a heal, but b/c I made a really good application for them and got nothing they promised (yes I should've got it in writing, but hindsight's 20/20)

Well, with that said, give them the software,passwords and documentation. But politely explain to them that training the IT staff in Access is as far outside your job description as making the program was and that if they want training (read: they can't figure it out) to discuss a bonus or some other incentive. Just my $0.02.

 

[Glenn9999]

Most of the people covered everything....in effect you potentially caused more problems in the long run than you solved in the short run by this Access Development.

One of the responsibilities of the IT department is to safeguard the life of the company when it comes to IT. You opened a big kettle of problems and they are simply closing them. While hearing the "rogue IT" label might be stinging to you, it is good you were willing to take some initiative. The problem comes like what was described: What if you get hit by a bus, what if something happens to your "unofficial offsite servers"? What if a security issue happens (all a hacker would need is that front-end and they have a VERY good line at that backend, because Access files are NOT very secure. What happens if someone gets hold of that data file (Access encryption is not a pretty thing).

And let me explain the problem with using Access. Let me start by saying that the only good thing Access is for is a single-user thing. Like was pointed out, mother keeping recipes. You start getting into any multi-user situations there are a laundry list of problems with Access. I won't go into those, because that'd make this post unnecessarily technical (and this isn't the forum for it). Let's just say, Access is at the rock-bottom of the food chain when it comes to the kind of databases out there. And likely, the company has a better DB solution already in the shop (as well as a better "front-end" solution too).

And let me explain the teamwork issue with an example. When I was working, our "user group" we were supporting went out and did something like this (actually they contracted it for $60,000 out of THEIR budget). Of course, we knew nothing about it...while...we were developing the same functionality for the systems already there. The users were working AGAINST us and not WITH us (and yes they caused more problems than they solved). I wasn't around long enough to see HOW they were solved, but it was a lot more time, trouble, and money with the bottom line of the organization (that's what counts here) - at least $60,000 but I wouldn't be surprised if their "rogue IT purchase" cost double or triple that to the bottom line by the time things were said and done with all the problems it caused.

"Rogue IT" means this: You worked against the company's bottom line, and didn't work for the company, but went off on your own. They are right as well, you opened up a boatload of problems for yourself, as well as your boss, I'm sure. (with my example, I'm sure the purchaser AND their boss were called onto the carpet.)

Just be thankful those potential problems (which the others outlined) are going to get taken off your plate (with time).

 

[dilettante]

Well, I'm not defending rogue development - but there are reasons why it exists. Some poor, and some with merit.

Let's just say, Access is at the rock-bottom of the food chain when it comes to the kind of databases out there.

Now there's a ripe-smelling argument, but I won't take the bait. The "right tool" is situational though, and most of the places where "Access" is a poor choice (and I assume you really mean Jet) pretty much any file-based DBMS is going to suffer (Fox, SQLite, etc.).

And likely, the company has a better DB solution already in the shop (as well as a better "front-end" solution too).

Wrong!

A tool is not a solution. Get your facts straight.

This is precisely the reason why a lot of rogue development occurs. Too many people are sitting back on their tools (or in many cases working their fingers to the bone with those tools) but not delivering enough solutions to meet the demand.


None of that justifies rogue development, and its negative consequences have already been described in detail. But it does leave us with a problem: how do we as IT professionals help address legitimate pent up demand?

 

[Glenn9999]

Now there's a ripe-smelling argument, but I won't take the bait. The "right tool" is situational though, and most of the places where "Access" is a poor choice (and I assume you really mean Jet) pretty much any file-based DBMS is going to suffer (Fox, SQLite, etc.).

Yes, any pure file based DB qualifies right alongside Access here. They all have the same problems in multi-user environments.

A tool is not a solution. Get your facts straight.

My facts are straight. Are you saying tools don't solve problems when applied? If I don't have my hammer and nails, how am I going to fasten the plywood to my roof trusses? That hammer and nails is going to solve a lot of my problems in that regard, so it's a solution. A tool too.

Too many people are sitting back on their tools (or in many cases working their fingers to the bone with those tools) but not delivering enough solutions to meet the demand.

In this story I quoted, the users WERE the main problem. They wanted everything right away. When the "solution" (in your terms) wasn't up and going in three months time, they started shopping for their own "solution". You can't provide things straight away. Not even Microsoft can take a big project (and this was that was replaced on contract) like Vista and go from drawing board to release in three months. And they even have different teams working on different projects (OS, Office, etc) More evidence: every "work request" had an expected completion time of the end of the day. No matter what. And that was their expectation too.

Of course, the user took over the work of the boss in scheduling the work. A big failure of my immediate boss and their bosses, but the immediate thing that needed done was that the user needed put in their place. Service is one thing, but a pushy customer does not deserve good courteous service in any event. A customer in a restaurant screaming "Where's my food" at the top of their lungs is no better than a customer screaming "Where's my system" a week after they ask for it. Which leads into...

But it does leave us with a problem: how do we as IT professionals help address legitimate pent up demand?

You don't. Where this was, we had an average workload for 3 times the number of personnel that we had. Either management needed to step up and give us more personnel or they needed to give support in putting the user in their place. Neither happened. And to bring up another factor, the quality of all the systems under our control were garbage. I wonder why?

Of course, in this case, and a lot of the others described here, it all points right back to management. All I was ever in a position to do (or my immediate boss) was just take the work and do the best possible thing and turn it out as fast as humanly possible. After all, if I could do miracles routinely on command, why would I want to be stuck in a cubicle farm for 8-10+hrs?

 

[dilettante]

Oops, sorry.

I wasn't speaking of your particular case, I meant to address the spirit of the thread in general.

Yes, I acknowledge that a lot of rogue development comes about just because somebody got his hands on some power (or not-so-power) tools and finds it more interesting to use those than do his actual job. Along with that come all of those clunky, dangerous, undocumented, and unsupportable "pocket applications" all over the organization.

But a good "hunk" of the rogue stuff attempts to meet real, unsatisfied needs. Even if it's just 10% of the rogue applications it can still be a lot of un-met need.


If the answer isn't going to come from "management" and it isn't coming from "us" (whoever "us" is - perhaps you mean official corporate line-o-biz developers?)... who is going to do it? It doesn't sound like you deny the need is there. You sound like you're as caught in the gears of the machine as Joe User.

So where does this leave us? Just whizzing into the wind, i.e. venting?