911: My project is slipping by

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:

Release is comingNot 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.

Quiet please... Silent changes in progressSilent change is when you open the application on the release date and choke on your coffee – a button was moved to another window, a feature was removed from production, you name it.

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.

Build notification exampleThat way, you always know when a fix is ready for you to document.

But!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.

Start watching this issueIf anyone graciously updates issue description or adds a comment, you’ll be right on it.

But!Did you know that we see the sun as it was 8 minutes ago? I mean, that’s how much time sunlight needs to reach the Earth. Well, time distance from a thing done and thing reported is much bigger.
So yeah, your issue tracking tool reflects the actual state of things as it was about 8 minutes two weeks ago.
Getting people to keep the issue tracking tool updated is not exactly the InfoDev’s cup of rum, but if you can assist your PM or SCRUM Master in this matter, you’ll also find that you’re helping yourself.


At the most, create labels and ask your team members to use them for all documentation-related issues.

Labels sampleA 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:

  • Doc-arch
  • Doc-ops
  • Doc-help
  • Doc

Just in case your team members are not sure about the impacted deliverable, they can use the general category –‘Doc’.

But!Getting your team members to remember about your labels is not easy – no matter how many times you appeal to their conscience, the obtrusive this-is-your-call-of-duty approach rarely works.But come on – we’re InfoDevs, and creativity is our middle name.
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.

But!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!

Advertisements

One thought on “911: My project is slipping by

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s