Why Projects Need Concise Writing
Reading time: 3 minute(s) - 600 words
Projects need documents. Big projects result in a lot of management documents and there are reasons for that. It means those documents need to be well written. Something that is easy to overlook.
I sat down to write a novel. This was not the first time I’d tried to write one. I wrote three chapters at a good pace. So I started planning the fourth. Then, I realised what I’d written wasn’t a novel.
I sat down to write a new novel. I crashed out 18,000 words in short order. One evening, I decided to read through what I had.
It wasn’t a novel.
I could give you more examples, but you get the picture. Some of us aren’t meant to write novels. It takes a certain writing style. And you either have it, or you don’t.
Most people can tell a story. That’s not the same process as writing a novel. I once wrote and published a short story on the web. Many who read it thought it was a true story.
Either my writing style is so compelling I convinced the readers they were reading something true. Or…
I write in a way that is factual, not suited for spinning a yarn.
Here’s the thing: I completed a diploma in freelance and feature writing with the London School of Journalism. It had a profound effect on me. Or on my writing, to be accurate.
I’ve discovered that I don’t like verbose, lyrical writing. I’d rather say it and move on.
You can write a novel in a journalistic style. Hemingway managed it well. So I haven’t scrapped the idea of writing a novel — yet. I need to approach it in a different way. That’s what I’ve learned.
Back to projects…
But what’s any of this got to do with writing project documents?
We all have a writing style. You may not realise you do. You may not care. But since writing is communication, (yes, even a text message or email) you don’t want to be misunderstood, right?
When producing project documentation ( the project plan, the business case , etc.) the documents need clarity. But they don’t need to be so formal that they make your eyes glaze over.
I’d argue that’s true for all business documentation. And it’s definitely true for software documentation.
You are not writing the next big blockbusting novel. But you are writing something that will be read by others. And it’s stuff that is key to the success of the project.
That makes it worth spending some time getting right.
Here’s a couple of things to consider.
Many years ago my dad taught me the ABC of writing.
It stuck with me since then.
Make it accurate, keep it short and to the point. And make the message(s) clear.
Business writing and ergo, project documentation, benefits from this approach. Nobody wants ambiguity in a project brief.
Nobody wants to plough through reams of wordiness, either. In project documentation you need to make the point. But then? Get the hell out of there. Keep it simple.
Read it out loud
Another trick is to make sure you read out what you’ve written. You’ll spot the clunky bits straight away.
A final thought…
Jargon, big words and verboseness makes writing hard to read. Why would you want your writing to be hard to read?
Nobody sets out to write unreadable stuff. But it can and does happen. Project documents need clarity. It’s that simple.