The phases of project initiation and project closure are substantially covered in blog posts, talks, and other resources across the TechComm society. Today, I would like to address a less frequently discussed phase – replacing a technical communicator in a project team.
One of the typical ways for agreeing to have project documentation in place is this:
- Customer voices the need for documentation (on a side note, product-based software companies are not considered in this discussion).
- Documentation team provides the estimates.
- Estimates are adjusted and approved.
This works well for new projects and new features in existing projects. On a side note, this also assumes that the people who give the final approval for documentation do understand why documentation is needed.
But what about legacy projects, the ones that are poorly documented or not documented at all? How do you convince the company (or the customer) that documentation is needed?
Last week, I attended a fantastic tech comm conference – Write the Docs Prague 2018. Hosted for the fifth time in the beautiful city of Prague, WTD allowed me to meet, chat, and share the experience with the fellow tech writers, information architects, and information developers from all over the world. Exciting!
Write the Docs is one of the most prominent technical communication conferences that brings people of the documentation development field together, promotes sharing of ideas, as well as encourages professional development.
I cannot but share the gist of 3 talks that boosted my motivation and inspired me at this year’s conference in Prague. Continue reading
Earlier this summer, I had a chance to attend a lecture called “The power of deep interviews” by Maryna Ptashnyk of Bambuk Design Studio. Targeted at designers doing field interviews with customers, it provided several tips & tricks that made me rethink how I myself as an Information Developer prepare and ask questions during the interviews.
When I heard the news about switching to Scrum, I was at a loss. The first question that popped up in my head was “How am I going to write documentation for the feature that is not there yet?” According to Scrum, everything should be finalized at the end of each sprint: working feature and corresponding documentation.
Proudly presenting the slides from my talk at Write the Docs Europe 2017, now on SlideShare!
Plus, fresh recording of the live talk.
For those of you who missed it, here’s a short intro.
Every doc that you deliver is as useful as the requirements it satisfies. Typical requirements revolve around target audience, method of delivery, technical limitations. But after the doc is done, then come unexpected expectations. John – your key stakeholder – dislikes clichés like corporate templates and wants to stand out with neat Apple-styled docs. Also, it was a mistake to tell him about similar ‘really cool docs’ you already did for his colleague Jane because apparently they don’t get along well, and now he proudly decided that he won’t mimic her decisions… Suddenly, your docs should not only make users happy, but also help your stakeholders achieve their aims – move up a career ladder, impress the manager, get a bigger paycheck. The success of your docs depends on requirements that you are never told but are still expected to meet. This presentation is about reading your stakeholders and deducing the ultimate requirements.
The 7 Habits of Highly Effective People by Stephen Covey. Book Review.
In the last decades, motivation literature has flourished to an unprecedented extent. This is a cultural phenomenon that cannot be missed: people have become interested in self-development, constant improvement, and success. “Ah, yes, success…”— you may sneer skeptically just as I did when I first saw the name of the book. Yet, behind the mainstream title, I found deep thoughts that are applicable in my life journey.
In her recent post, Natalia Bortkevych very astutely described the typical cases of SME interviews gone wrong.
In truth, when the subject is confusing enough in itself, it helps little to have an SME who has aversion to human race or talks in the “codish” variety of English.
Still, even if your SME is able in every way – approachable, knowledgeable, adorable – it’s no guarantee they will be willing to grant you an interview or a review if they are busy, even if you sorely need it. On the other hand, if you are disposed pleasantly towards each other and get along well, they’re bound to be more cooperative.
And while there are many tips and techniques for building that connection with your SME, sometimes it just happens naturally. It’s much like falling in love – you just have to find the right person.
We have designed this test to help you find out what kind of SME is your natural match!
Interviewing subject matter experts (SMEs) is one of the key soft skills that an Information Developer should possess. Our job is to get the technical input and turn it into a clear and usable output: decide on what is crucial and what is irrelevant, structure the information, and illustrate it with examples or graphics. Still, the much-needed input resides in the minds of the SMEs, and we need to act wisely to retrieve it—in other words, to master the art of interviewing.