Some project days make even the most stress-resistant Technical Communicators (a.k.a. Information Developers) get the jitters. These are the days when a foreboding PM’s voice proclaims:
Not because we are behind our documentation plan schedule. Not even because the product environment is unstable. The truth is, I’d rather face a bunch of White Walkers than a couple of silent changes.
Silent changes cost us a lot of nerves, undermining the credibility of our documentation and making us wonder what other changes we’ve missed.
Suddenly, it dawns on you: you know nothing, Jon Snow.
This article shares a couple of ways to reduce the probability of silent changes. Every project has its culture and the way things are run.
Still, I hope that you can make the most of these potential allies.
Your ally #1: Build server
Just when you feel that you’re losing the grip on your project’s events, go ahead and ask your DevOps to sign you up for build notifications.
Such notifications arrive whenever a new build (application update) is generated. A build notification usually contains a list of all commits and accompanying comments provided by commit authors.
Most of the time, the commit comments are hazy or uninformative. Luckily, there is a rule of thumb – ask you team members to start each comment with the number of the related issue from the issue tracking tool. That way, you’re always in the context.
Your team members may argue that they commit many small fixes related to many issues in one go. That’s the signal for you to suggest the ‘one fix–one commit’ policy. After all, everyone will benefit from it. Yeah, that’s another tip that works – never start with ‘I need’, because who cares? Start with ‘we need’ and sound like you mean it.
Your ally #2: Issue tracking tool
At the least, in your issue tracking tool, you can start watching issues that have a bearing on your work, such as an epic with a specific use case.
In JIRA, it’s a one-click effort.
If anyone graciously updates issue description or adds a comment, you’ll be right on it.
So yeah, your issue tracking tool reflects the actual state of things as it was about
At the most, create labels and ask your team members to use them for all documentation-related issues.
A single label like ‘Documentation’ would work if you had one deliverable. However, if you’re maintaining a full set of documentation deliverables, you’ll probably have 90% of issues labeled as ‘Documentation’.
So, in this case, you might want to create a set of labels, for example:
Just in case your team members are not sure about the impacted deliverable, they can use the general category –‘Doc’.
For example, here are a couple of sneaky techniques that work for me:
- Use your Skype status to deliver the message (for example ‘DOC labels’).
- Have the labels printed on a T-shirt and wear it once in a while.
- Place a bowl of sweets on your table with a note like
Put a DOC label? Try a sweet.
Didn’t put a DOC label? Try to sweat, then try a sweet.
The most important point is – if you notice that an issue lacks your label, don’t DIE (Do It Eagerly), because you’ll end up as a label-placer until the project ends. Come up sweetlike to issue owners and kindly ask them to put a label themselves. Every time. Because repetition leads to habit.
If all this sounds like too much effort, maybe you don’t need those labels after all. Just keep your eyes open for new issues.
Your ally #3: Status meetings
Wait a minute. What do you think you’re doing, putting on your headset and turning up the music?
Don’t get me wrong – issue tracking tools and build servers may provide the needed info, but they cannot substitute live communication with your team members. We always need to return to the source, you know.
It’s really useful to get a seat in the room next to your key SMEs (BA, QC, or other). That way, you have a good chance of overhearing about last-minute changes and fixes that float in the air but often don’t make it all the way to team chat or issue tracking tool.
However, your best informer about project events is a status meeting. If it’s daily, you’re in great luck.
People tend to be very general and random when talking about their statuses. So, with time, status meetings become nothing more than a forced tribute to SCRUM (a.k.a. waste of time).Be honest, how many status meetings have you spent nose down in your phone? There is a way to make status meetings meaningful for you. It is as simple as using your vocal cords.
- Whenever you hear a generic BA status phrase like ‘attended a couple of meetings with the customer’, ask for clarifications:
Any changes to the requirements expected?
- QCs like to say ‘created a couple of bugs’. Go on and ask:
Is any critical functionality broken?
- Developers like to parry QCs: ‘fixed a couple of bugs’. The best way to elicit a more coherent status is to ask:
Did those fixes impact the UI in any way?
Try to look up from your phone – eye contact helps.
Your ally #4: Tequila
Just a joke. It’s rum. But only as a last resort, after you try the following:
- Sign up for notifications from the build server (ally #1).
- Watch issues and use labels in your issue tracking tool (ally #2).
- Be proactive during status meetings (ally #3).
I’m sure you too have ideas and tricks about keeping your project from slipping by. I’d love it if you shared!