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.
