"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

 

[sleipnir214]

I don't see why you'd even consider fighting this.

Want the best answers? Ask the best questions:

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

TANSTAAFL!!

 

[vbainchicago]

Really two issues

1. Our workflow and requirements change often - monthly is not unusual. I can make db changes quickly, and my IT department will not. The barely even support the systems they developed - the average help desk ticket or system change takes weeks - if not months. Handing my work over won't do anything but make my, and my coworkers jobs, more difficult.

2. It's my work. I took the initiative, worked through all the problems, and support all the users in my area if they have problems. I take a bit of pride in what I've accomplished, and would hate to see it's use and importance diminish when the users couldn't get things changed, added, or fixed in a reasonable amount of time. Not to mention that their inability to do their job adds more work and stress to my job.

I don't have a problem providing some documentation, but think it insane that I won't be allowed to work on the db I created.

It's not about "fighting it", it's about doing what makes sense. I just don't get where they're coming from or how it benefits anyone.


VBAinChicago

http://www.jjscomputing.com

For Fun -

http://www.321google.com

 

[VE]

I don't have advice, but I can tell you I understand what you are saying. My own experince is very similar. I started out as a Buyer/Planner and when the IS department did not have the time to understand the reports I needed I ended up learning how to write them myself. In later jobs I have written Access databases too, but mostly I write reports.

A lot of time, people who have never done a job just don't understand why certain data is needed.

Personally I'd be furious if I had to hand over a database *and* teach the person Access, considering they already don't know purchasing.

 

[vbainchicago]

I gues it's more aggravating than anything else. The db has functioned almost flawlessly for years, I've NEVER had to request any IT assistance to keep it working, and it it makes my and my co-workers jobs much easier and efficient.

I wouldn't say I'm furious, but I'm surely confused. I just don't get the logic, or the benefit, to handing anything over.

VBAinChicago

http://www.jjscomputing.com

For Fun -

http://www.321google.com

 

[edfair]

Gotta understand. You "rogue IT" guys may make the IT department look bad. If they can't control it, their entire structure might fail. Getting the work out on time isn't one of their priorities.
You'll have to give it up. But expecting you to train your replacement is the pits.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[chiph]

You gotta realize that IT has a mandate to make the information systems in the company work in order for the company to be profitable. If you were to be hit by a bus, the systems you've written would be unsupportable by them, and when they broke (all systems break), profits would take a hit as your department works to figure out how to go back to doing things the old way.

So, don't get all bent out of shape by this. In a way, they're recognizing your hard work.

I don't doubt that they could have put it to you better. But it sounds like your boss had no choice in the matter.

Chip H.


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

 

[DrJavaJoe]

You have an IT department that can't figure out Access?

"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'."

 

[sleipnir214]

vbainchicago:
It's not your work. You've admitted that you worked on this app on company time, so it is at least partially the company's work. Create something on someone's payroll, and that someone owns the product -- that's the law.

All of the data in that database is the company's, and you do not have the right to lock the company out of it. Keep up what you're doing, and someone in the company may arrive at the conclusion, true or not, that you are holding their data hostage, which is not a good position to be in.

I see no way you're going to win this one. The question is: How much do you want to lose?

Want the best answers? Ask the best questions:

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

TANSTAAFL!!

 

[philote]

I'd say you should definitely document the design as this is just good practice. As far as training an IT person in Access, I say screw it. They're in IT and should be able to take a few training classes and read a book to learn what they need to know. Once you have given them documentation and the passwords, let them take over your system. You should also clarify with your boss that though you're unhappy with this, you've done as they asked and working on this system is no longer part of your job. If they need something done (which it sounds like they will), tell them you do contract work on the side and you'd be happy to charge them for help or take the system back. Maybe that's a little harsh and maybe it won't fly, but I think it's rediculous that they want to exclude you from developing this or any other system after all the work you've done and time you've saved.

 

[Dimandja]

vbainchicago,

1. You developed that system on that company's time: the system belongs to them, not you.

2. You developed the system for 4 years without any official backing: somebody (you or your boss) was asleep at the wheel. You effectively hijacked this company's data and expenses; now, they want their stuff back. Give it up, none of it belongs to you.

3. Of course you are smart; that's why they kept you on the payroll for years. It does not mean you are the owner of anything you had been working on. This company can sue your socks off; you haven't got a leg to stand on.

4. Next time you decide to develop software for sale, do it on your own time. And that's also why you didn't have much competition where you work.

5. I may sound harsh; that's because there are too many ITers out there who go out of their way to "develop killer apps" on their employer time, and then try to claim the work as their own: the law is against you on that one.

Although I applaud your valiant efforts at software development.

Dimandja

 

[dilettante]

I've been through this on several occasions, from the IT end.

Typically this sort of thing comes up when one of three events occurs:
[ol][li]Somebody leaves. Nobody can operate the "application" any longer.[/li]
[li]Some problem occurred in the data or in calculations, and an embarrassing incorrect business decision was made or report was released - and only discovered after the horse was out of the barn.[/li]
[li]An IT auditor stumbles over one of these things.[/li][/ol]These are all very bad and can be very costly. Audit reports for public organizations can end up in the papers. This happens to private or traded organizations as well, and they'll get to the officers, owners, or shareholders for sure.

Normal IT development processes are supposed to include a large number of "overhead" activities that can make or break any application that manipulates or stores corporate/government information assets. This is why it can be so important to try to draw the line between office desktop computing activities and "rogue IT operations."

Even these processes are imperfect, often imperfectly or incompletely implemented, or sometimes disasters in themselves. But this is a part of the "due diligence" required in IT development activities.

Just some of the things that "rogue" IT activities typically lack (not that every official IT development group always does them well or completely either) include:
[ul][li]Application requirements documentation[/li]
[li]Application life-cycle plans[/li]
[li]Code reviews[/li]
[li]Testing and results validation[/li]
[li]Program source control[/li]
[li]Code modification logs and authorization records[/li]
[li]Code and system documentation[/li]
[li]Operational and user documentation[/li]
[li]Run schedules and assignment of run responsibility[/li]
[li]Granular application and data security (different rights for different folks)[/li]
[li]Transaction logs and activity reports[/li]
[li]Separation of duties between developers with access to the code and those permitted to run the application and handle production data[/li]
[li]Data retention requirements and disposal schedules[/li]
[li]Data backup and archival requirements and procedures[/li]
[li]System maintenance schedules and procedures (database compaction, user/password changes and resets, etc.)[/li]
[li]Report and extracted data recovery procedures[/li]
[li]Database recovery procedures[/li]
[li]Risk assessment and disaster planning[/li][/ul]This is a whole bunch of stuff!

I've been on the unpleasant side of enough audits to know what it can cost you. At best (if things go pretty well) you end up mired in compliance efforts that eat productive time. Not everything is subject to all of the items above (and more), but that's where the risk assessment comes in.

 

[dogbert2]

It's a sad state of affairs when I.T. Departments have to admit they don't know access, or other common place tools which are in use in the office. I try to learn as many things as possible in the scope of my job to keep current, but is it any wonder that employees get fed up with departments which can't do the simplest things correctly, and it sounds like to me, if the I.T. department wants to assume responsibility for the work, they can field all the calls that go along with it (just make sure you make a copy of the work for safe keeping) and that you list this on your resume' (along with the proof to back it up), just in case.

 

[dilettante]

Even with all of my blah-blah-blah up above, I can only agree fairly strongly with dogbert2 and others.

In many organizations the "official" IT development staff does a very poor job of supporting desktop computing efforts. Even if we restrict ourselves to the small universe of the Microsoft Office suite, there is a lot of power there that goes unexploited. Instead of offering useful resources, training, and general guidance there is a tendency to try to just cut their user community off at the knees.

Some places where I've worked "advanced" Office applications from the official Office support folks consist of things like poorly designed forms in Word laden with auto-triggered macros that make completing the forms a nightmare of unexpected jumping about and side-effect actions. Many of the "official" Access applications offend against my list of "overhead" requirements above as much or more than user-developed applications.

Other organizations do a pretty good job though too, and have a quick and clean process to do a first cut at risk assessment. For lower risk desktop and office-level projects they tend to be quite supportive of user-developers, and offer both training and consultation services (sometimes outsourced to a local company or individual Office contractor). Cost containment is always a problem here however, and I know two places where this practice was halted in the last couple of years.

I think most organizations choose to see worker time spent on development as wasted time. They are willing to accept the tradeoff of missed productivity-enhancement opportunities to make sure the workers are performing their primary tasks. For all of the talk about "knowledge workers" (or is that now considered an obsolete 1990s concept?) I find that in my corner of the U.S. market anyway upper management wants an army of toiling drones today.

Call it... "Business II" (not not be confused with a similarly titled magazine). ;-)

Oh well, time to switch to decaf I guess.

 

[edfair]

After rereading your original post I would anticipate that you would need to give the "IT" people any of the relevant documentation regarding the existing databases along with the passwords used to access them.
You job title isn't software trainer so I would suspect that you have a legitimate reason to decline the training, besides which, if they are professional, they can find their own training. If they insist on training, then your boss needs to be the one to tell you, since it will impact your normal job. Let him make the decision that will impact his department.

 

[Dimandja]

About IT departments not knowing anything about MS Access.

This is actually to be expected of very sophisticated IT shops. Access is not used at all by any IT that develops serious software, because it is an inferior database system: very unreliable and very buggy.

Dimandja

 

[theoxyde]

Agreed. Access is not as ubiquitous as other technologies, and so I wouldn't expect anyone to know Access that wasn't specifically trained in it. That said, though, it doesn't take very long to become an expert in it if you know VB.

There is a fine line that must be walked with "unofficial" software designs. They increase employee productivity, but can also be a liability. That is something that individual companies will have to decide for themselves. In smaller businesses, a user-designed app may not be a big deal, but in a large company, the risks far outweigh any productivity gains.

I will admit though, Access does have its uses. One of my developers uses Access to prototype application design ideas. We don't use Access for anything else, but she is able to make quick-and-dirty designs during meetings with clients to flesh out ideas.

 

[SemperFiDownUnda]

I agree your systems should be documented so that if you "are hit by a bus" others can be brought into take your place.

I'd respectfully point out to them that you'll document these tools you've created but consideration for your normal work load must be taken into account. Point out the time cost benifits that your tools have produced so far. They can't expect you to double your time working essentially because you've mad everyone elses job in the dept easier.

Point out that they always have the option of not using your systems all together and go back to the complete manual way of doing things. If your systems are that good at improving productivity the department should maybe take up your normal workload while you transfer these systems over.

Explain that someone in purchasing (you for now) should be designated as the key user. When you have issues getting changes made write up a report saying how long the change would take to develop and what its costs savings would be in the short and long term. Heads will turn when you can show a 8-12 hour change will save 80+ hours over the short term and even more in the longer term.

Also point out that more than one IT person will have to be trained in Access and this system or else they just shifted the risk of you getting hit by a bus and the systems being unsupported to Joe Bloggs.

The IT department is half doing this because of risk. At the very least there is a high risk if something does happen to you that they will be left out in the cold because they don't have access to the password thus can't even bring in anyone to make changes if needed.

Maybe you should look at this as an oppertunity to get into the IT dept. It sounds like your IT dept is mostly network type IT and not a lot of developers. Perhaps you could get in as a desktop developer.

1 thing you should definatly not do is get emotional about "Your systems" they are not your systems ... you wrote them on company time. I know you, as most of us do, take pride in your work but I also know to well how emotional people get about "their code". Ask a developer "Why did this crash?" and most will get defensive and try to shift blame to something the user did. In the end 95%+ of problems in software is the programmer/analysts fault not the user but we never like to think that.

So try to decouple yourself from the issue emotionally. Come up with some logical solutions and arguements and back them up with real data. It becomes alot harder for bad decisions to be made when you make logical, informed arguements without any emotion envolved.

Also when you do goto them and talk about when needs to be done ask them for their programming guidelines, ask for their templates for requirement and technical specifications so you can document it in their format. If they give you a blank stare then you've got even more ground to stand on when suggesting that you maintain the development of the systems.

Biggest thing agian....don't get emotional....you'll make better decision overall. You never know you may find out that you can make some change in the IT dept. Oh also read and fully understand the LoS agreements your IT dept has with the rest of the company. If there is non you should also suggest they get implimented or your application might as well get thrown out the window now because there is no assurance that support will be sufficient.


Hope I've been helpful,
Wayne Francis

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

 

[benlinkknilneb]

Thought I'd weigh in on the subject:

I personally would JUMP at the chance to teach my IS/IT department if they're going to use my database. Oh, sure, they could learn it on their own... but I'm a little protective of my databases' structures, and if you're concerned about the usefulness of the application, now is the perfect opportunity to teach them the design principles you've used. A lot of people can interpret things differently when they read it out of a book... and this is a chance to nip it in the bud.

It sounds like the office political system has been circumvented... and that's probably why the IT people are so up in arms about it. Provide them with the documentation and ability to edit the database, but ask to retain passwords so that you can add things to the program quickly if needed. Then everyone's needs can still be met... they'll have the "hit by a bus" contingency plan, and you'll still have a quickly adaptable system.

Just remember that they are IT, not you. They won't like it if you tell them what they should do with their computer systems. Reiterate repeatedly that you're working with them, not against them, and be sure to start informing them when things happen concerning the database.

Good luck!

Ben

There's no place like 127.0.0.1.

 

[lionelhill]

Don't feel challenged. It's the IT department who face all the stress. You've got a working situation that your department is happy with. They want to take over - anything that goes wrong leaves them looking silly. The best thing is to help them as far as possible, even though it looks like damaging yourself. It's better to have friends in the IT department than alienate them. But having said that, it's worth being up-front about what you will and won't do. If they want to officialise the whole unofficial system, fine, but they can't expect you to do all the difficult support and training while they take all the credit!
And yes, Access might not be the tool they'd have chosen, but anyone who wants to be considered even half-way knowledgable about databases needs to be familiar with Access because it is most people's first entry into databases. It's not like you chose some strange package no one could ever have heard of.