February 2014

My co-worker, who is on the road at various customer sites, sent an email to me which included the following:

On a side note, when I mentioned that we are finding out all the functionality changes through the grapevine or really late, and you asked how we were getting our info, what/who were we meeting with to get our info? Obviously that communication is broken, should we be meeting with [co-worker A] or [co-worker B], or someone else? Everyone seems like they are getting their butt kicked by workload, but we've got to find a better way to share some of this info about status and changes to the platform. Any suggestions?

This is what I wrote back to him:
|
We got the instructions done, sent out for approval and then ... crickets, Eventually, the only feedback we get is to be asked to make more words bold. Everyone's a writer and it makes me chuckle. I don't have any concrete suggestions. We're all in a definite trickle-down thing - it's not just you - I feel your pain. The docs are under tremendous scrutiny.

Recently, it seems like every customer / program wants their own version of the doc. That is complicating things immensely. We are trying to, simply, document the system and what it can do. Traditionally, there has always been this cross-over of process being integrated into the user guide. For example, a team just took back maintenance of their doc because they want the name of the user role that can do the procedure appended to every title in the document. We said, "No." They said, "that's what the customer wants."

It's more unfortunate for them more than us because they don't realize what they getting into, which is a customer-specific user guide that is modified whenever there is a new issue that comes up. The logic seems to be that if the doc has the information, no one will ever have the same tech support issue and that's just not reality. This specific program also is allowing the customer to approve the content so, despite all the top to bottom "one company" unification effort, we are going to continue to have user guides that look different in formatting, in content (the way things are worded), and such. I know the customer pays all of us, but there's this line in the sand where what they want is not in their best interest and not in our best interest. It's up to us to say, "No" and offer an alternative to things they think they want. I don't envy you being on the front line like you are. I know it's easy for me to sit here, not being in front of the customer and to spout off about how things should be. For example, I would have suggested that, instead of listing the user roles in the heading of a procedure in a user guide, create a version of the user roles matrix and say "If you are Role A, you can do this list of procedures in the user guide." It would separate the tasks the system can do (which is what the user guide should be) and what the users can do with it to complete their processes. Instead, the customer asked for something and without thinking through what that request meant to the entire structure, we gave it to them. I can tell you that no one on that team has the time to do what they've agreed to do and if I were a betting man, I'd bet that at some point that user guide comes back to my team and we have to have a discussion about system documentation v. process documentation. I don't see us maintaining the user roles in the headings when it does come back to us.

Sorry to monologue on you. I'm actually being shifted to a different project that has a deadline of mid-April. With all the other things that have been happening, I'm not as far along as I'd like to be. I will definitely do what I can to help you. Any feedback you get from the customer is always appreciated so if you get it, send it our way.