Constantly repeating myself to coworkers about processes

Question

I've been at my job for a few years and over the past six months have sort of become my office's main go-to for database needs and improving internal processes. It's very much dependent on what projects need within our office (so if there's nothing of that sort to do, I'm put on another task) and meant more as a tide-over until I'm promoted into a different role.

Recently, I've become frustrated with some coworkers, specifically project leads, who seem to gloss over the information I provide them. We're not on bad terms, they just don't seem to retain anything I've been working on related to their projects and I'm constantly needing to repeat myself on work matters I've explained multiple times. A recent example that's stuck out to me is an email chain I've had that went like this:

Me: Going forward, project X will need to process their numbers using method Y. I've attached a document with a step-by-step guide.

1 week later

Lead: How do we process numbers for project X?

Me: Method Y, as outlined in the email I sent a week ago.

Lead: So use Method Z?

Individual verbal explanations and group meetings haven't fared any better. Currently, I've recommended to my manager that we need more documentation for the things I've done, which I previously had no time for because we were focused on rolling out new projects as quickly as possible. I started small with some <2 page documents for a few critical processes and the response I got, a few days after I sent out the announcement to go through them and make sure they're understood, was basically "you sent out an announcement?". I'm not terribly excited about having to release much larger documentation with detailed information on the databases themselves, if those are going to be ignored also.

With all this in mind, is there anything I can really do to fix this apathy I'm seeing? I realize that as the person building and conceptualizing these processes and databases that I can expect to get some questions about how everything works, but it really just feels like I'm doing all the thinking for coworkers who really should have a better sense of self-autonomy.

Answer 1

It's good to have in place some system of document control with active SOP enforcement.

Ideally, you as the originator would put together a document for your process that anyone with some experience with the system could follow and get to the same endpoint. Then you'd have it reviewed by a direct supervisor, have QC/QA sign off on that and get it filed somewhere accessible.

The other requirement, and most people miss this, is you need to train personnel on SOPs and have them sign off that they understand the document.

Typically, you include a statement of scope: where does the SOP apply and to whom? That way it's understood that work on project X is, in part, governed by the methods outlined in SOP-ABC-xyz. From there on the SOP is enforced by management, and instead of emailing you or searching around to piece together the required know-how, all I have to do is go find the PDF (no questions asked).

The primary issues are poorly written and/or unenforced SOPs, and my favorite: the documents exist but no one knows where. It's not a process to start alone, so I highly recommend getting a manager involved!

Answer 2

Clean up your communication. In scientific texts people would tell you to cite/reference your sources correctly. It also works in this case.

So a cleaned communication from you example could go like this:

Me: Going forward, project X will need to process their numbers using method Y. I've attached ProjectXNumbers.pdf (the exact filename) with a step-by-step guide.

Lead: How do we process numbers for project X?

Me: Quote (use forwarding from your original mail, it has timestamps and all you need): Going forward, project X will need to process their numbers using method Y. I've attached ProjectXNumbers.pdf (the exact filename) with a step-by-step guide. Do you need me to send you ProjectXNumbers.pdf again, or do you have it available?

Lead: So use Method Z?

Well, this should not have happened at that point. In the worst case, re-send them the full original mail. Or set up a meeting/phonecall to clear things up.

Answer 3

If your colleagues are anything like the ones I had in my previous work, they are likely to be adverse to read anything that is longer than a paragraph (maybe two) at the time.

I would recommend splitting your documentation in very small parts and to provide it as a wiki or something that could provide an internal search engine.

I see two main advantages to this: you can write up the documentation as they ask you questions and then you can always just provide the link to the subpart they ask about. Hopefully, they would then pick up from there and read the rest of the protocol.

In general, provide the information in a written format - even if it is a powerpoint, as you can always reference it later.

You can then answer any later repetitive request as their question being quite important you did document it previously and they can found it in that powerpoint from the slide XX.

Answer 4

With all this in mind, is there anything I can really do to fix this apathy I'm seeing?

You probably cannot fix apathy. But with your management's permission, you may be able to enforce standards.

Talk to management about the need for standards and ask for permission to be the "gatekeeper". Then inform the project leads that they must pass a review of their code before it can be promoted to production.

Set up trainings and documentation so that they are adequately prepared, then start the new process.