Summary: I'm a developer, and currently also do support for the stuff I develop. Due to organisational reasons I'm being asked to hand off the 'support' function to a dedicated support team, but they want everything to be 100% in "checklists" that can be followed without detailed knowledge, and I think they're asking for the impossible. Some amount can be made into checklists and documentation, but some requires specialist knowledge and an intuition for problem solving.
I'm a 'senior developer' but also carry out some applications support processes for the systems I work with, which are both internally developed and things like 3rd party system we integrate with ("making our software work with Google Maps to show the 5 closest branches" type of thing). Applications support usually involves troubleshooting, answering questions from internal people, etc. but I don't talk directly to our "end user" customers. The systems we develop/maintain are part of the business but the software isn't our 'product' as such.
Lately due to various factors (staff cuts - layoffs and people leaving and not replaced, inefficient use of developers' time, probably other management reasons) we have an initiative to shift the support-type work to another team (within the company) which already deals with support work for some of our other systems - we're a fairly large, multi-site company so it does make sense to 'centralise' this kind of support work.
As part of this handover we're being asked to create documentation for how to run the various processes (e.g. there are some things we have to do after each Month End), resolving issues etc. So far so good and I have created a number of checklists, how-to guides etc etc. to facilitate this.
Where I'm having problems - and where I need your help :) - is I'm struggling to explain that some processes, systems and problems don't fit neatly into a "checklist", "if then else" thought process as they require a kind of intuition for problem solving, diagnostics, "following your nose" to find where a problem may have originated, etc. We're being asked for checklists, procedures etc which cover all the cases of (e.g.) "what can go wrong and what to do about it".
As an example (please don't get too hung up on the example as I have just made up this one to illustrate the sort of thing I mean):
- Checklist item - Copy this 4GB file to the 'XYZ' network location.
- What could go wrong?
- File doesn't exist so I can't copy it.
- ok, let's check if the process that was meant to create the file has run successfully, by checking its log file. (Checklist item or common sense)
- the log file says it failed but doesn't say why! That's not very informative....
- (expected checklist process for the people picking this up): Follow "file doesn't exist" checklist. Here's a document of things to check for why it failed with yes/no criteria resulting in the step to carry out to resolve the issue.
- (actual thought process I would carry out): Check the obvious things, nope everything looks fine. Why hasn't it run then?? It's succeeded every time for the last 18 months! Hmm, I wonder what was running at the same time? Could it be a problem with not enough resources on the server, although I've never seen that happen before with this file? 4GB... is that the amount of memory on the machine where it's running? Could it have run out of memory? blah blah blah
- Following my nose until I eventually find out that it was due to not enough disk space somewhere in the process which after a load of other diagnostics, I find it was caused by a failure of some other process which no one noticed because..... etc etc.
It isn't possible (I don't think!) to create a checklist to completely replace that level of diagnostic, troubleshooting ability that comes from detailed knowledge of the system, experience, and just aptitude for that kind of thing. Maybe 60-90% (depending on the details) can be made into a checklist, and I'm happy to do that, but there's always that 10-40% remaining that doesn't yield to a "if then else" mindset.
Of course part of this issue is over-enthusiastic cost saving and trying to push off senior/expert level tasks onto junior people who can follow a "script" to resolve even the most complex issues.
I need to know how, or whether, I can communicate to the involved people (my managers, their managers, the support people themselves who I am meant to be handing over to) that not 100% can be made into "checklists"?
Currently they are refusing to accept the handover unless/until it can all be documented - we're under pressure to get it handed over but I can also see their point of view in some ways (although I wish they wouldn't apply such rigid thinking).
Help! (actual questions in bold italic in the text above :) as I know 'help' isn't a good Q&A!)
From an emotional point of view I feel a little insulted that they think all the years of knowledge and experience can be distilled into 'if then else' that can be followed without fail... and also because if I could sit down and write out "everything that can go wrong and what to do about it" it would mean we hadn't done a very good job writing the software in the first place! I don't think this is what they intend in asking that, but I do let emotions get ahead of me sometimes. Which is partly why I'm struggling to explain 'rationally' why they're asking for the impossible.