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?
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.
Guilty as charged, but PDFs are just the tip of the iceberg. This sticker caught my eye the other day and got me thinking. What do the stakeholders and the team think I do?
One of the things you need to give a thought to when preparing the docs is the user data that will show up on your screenshots and in your examples.
A very straightforward and down-to-earth example – the sign-up functionality for a website. Let’s take a very common case like signing up for Twitter.
A picture is worth a thousand words. And while reading the actual book may be the ‘proper’ thing to do, you can always get away with visuals & short summaries just to get a quick and easy grasp of what the whole thing is about. With that in mind, I’d like to share some of the resources based on Made to Stick by Chip and Dan Heath that we reviewed in one of our previous posts.
… people don’t buy quarter-inch drill bits.
They buy quarter-inch holes
so they can hang their children’s pictures.
‘Made to Stick’ by Chip and Dan Heath
A young and passionate CEO carefully crafts new strategy that will revolutionize the company standing and even the industry itself, yet his brilliant idea falls on the deaf ears of the stakeholders.
A dedicated scientist discovers a dead-sure cure for an untreatable disease, yet the scientific community dismisses the idea and leaves thousands of ill people in the dark although their lives could so easily have changed for better.
The marketing department of a food chain finds a customer success story that will make into a beautiful campaign for the brand, yet the management shrugs off the idea 15 minutes into the presentation.
It doesn’t have to be all that tragic, and contrary to what is seems, the actual villain here is not at all the thick-skinned management.
As an Information Developer, your work usually starts with opening an authoring tool of choice, creating a template and styles, writing the content, and producing a piece of consistent writing.
Well, most of the time. This applies to some 80–90 % of your time when you’re not busy digging information and interviewing SMEs. One of the things that you might be requested to do in your spare 10 % of time is to proofread some internal company or project documents. Usually, the process of proofreading involves Word documents and dealing with the following aspects:
- Spelling and grammar errors
- Naming conventions
- Overall structure and the level of details
A good spellchecker will save you the trouble of having to fix absolutely all spelling and grammar errors. There’s no proper artificial intelligence out there yet, so no one can handle structure and the level of details for you. But what do you do with formatting and naming conventions?
You can make more friends in two months by becoming interested in other people than you can in two years by trying to get other people interested in you.
Remember the usual TechComm trouble? Getting other people to acknowledge your presence and importance as a team member? Turns out practically everything that needed to be said was actually said a century ago.