Technical Writer

SharePoint’s biggest competitor is its own product sibling—the Microsoft Office Suite.

Office’s success means there is no real need for SharePoint.

Yes, SharePoint can provide added benefits, but today’s office can run without it. Take away Outlook, Excel or Word, however, and what happens?  Work grinds to a halt.

Take away SharePoint (but leave the other Office products), and people cope.  They go back to the old way of doing things, saving their file on local drives or servers.

While Microsoft lists SharePoint Server as one of its Office products, it is not one of the base desktop products that most people recognise as the Microsoft Office suite.

Nowadays most people are familiar with email, word processors and spreadsheets.  They learn about them at school. They know what each product does, and how. They are basic must-have tools to get by in today’s business and schools.

Try telling someone how important SharePoint is.  What do you say?  “It helps you collaborate with your team members.”

They say, “I collaborate anyway. We exchange emails all the time.”

You say, “Well, what about file sharing?”

They counter with, “I can use Windows Explorer to share files, and at least they’re still accessible when SharePoint is down.”

Ouch.  Because you know everyone remembers the times SharePoint goes down and their documents are inaccessible.

Anything you say can be done via SharePoint can also be done in another Office program. Issue lists—you can do that in a spreadsheet.  Tasks—you can do that in Outlook, if it’s your personal list, or a spreadsheet if it’s a group list.  It seems you can’t win.

The thing is, these people are right. Excel spreadsheets and Outlook mail are good tools.  Why bother with SharePoint when you already have something adequate for the job?

 

Over at I’d Rather Be Writing, Tom Johnson asks STC candidates to submit a story about a defining moment in their career.  I am not a candidate (or even a member) of the STC*, but like many of us, I do have a defining moment that has shaped my career as a technical writer.

It was my first technical writing job.

It was a big project.  We had a team of 15 writers. The team leader was very particular about grammar and punctuation, and he was an excellent proof-reader. As the greenest writer on the team he took special care to ensure I was up to standard. From a writing point-of-view it was probably the most polished documentation I have ever produced in my working life.

We were proud of what we had produced.

Until we presented it to the trainers who were to teach it to the call centre staff who had to use the new system. 

“But that’s not how the operators do it,” the trainers said.  “They take the call first and then …”

We had built our whole training around the system specs, not on the operator’s procedures.  (I haven’t come across this recently, thank goodness. It’s one thing we seem to have learned in the last ten years, that we should write around the user, not the system, but it was prevalent back then.)

Worse, our team leader took it as a personal attack. 

These people had a genuine issue.  It wasn’t with the writing, it was with the fact that what was written did not fit with their current policies and processes.  (We weren’t changing these, just changing how they carried them out on the screen.)  But our team leader treated it as if they were criticising the writing.  (Think of the most precious writer you know, someone who refuses to change even a word because his writing is perfect as it is, and you get the idea.) 

He started to defend himself.  Then he got vitriolic.  He claimed the trainers had no idea; he told them that if they couldn’t train the new system that wasn’t his problem.

It was a fiery session and I have to say that the trainers came out of it far more graciously than the tech writers did.

I still remember that meeting, and I still use it as the basis for everything I do in technical writing.  In particular:

• Always start with the user, not with the system.  As I said above, most of us seem to have learned that lesson now, but it’s a pretty important thing to remember

and

• Don’t take criticism of your writing personally.  People are commenting on the content, not on your writing. In all my years of technical writing no-one has ever used my writing to attack me.
• Listen to that feedback. People are saying important things about the content. Don’t let your ego get in the way.

Good lessons learned.

 

 

* The Australian equivalent is the Australian Society for Technical Communication—try http://www.astcstate.org.au/ where state is your three letter state abbreviation.

I’m having more fun with my TechNet subscription than I expected to.

It’s a 12-month subscription to pretty much every program Microsoft.  I purchased it because our work has decided not to upgrade to SharePoint 2007, nor to Office 2007, and I need to keep up-to-date with the technology. I am planning on moving on some time (hopefully this year).

I haven’t got around to installing SharePoint yet.  So far I have only installed the standard Office programs but it has been good to learn about each of the new versions. 

I know I could have run the trial version versions, but these are full versions and I don’t have to worry about time limits.  I can also test out various programs that I wouldn’t otherwise touch, like Groove.  (I still haven’t figured out where Groove fits in.  I mean, isn’t it doing similar things to SharePoint, only off-line?)

It’s not cheap, but it’s value for money if you intend to use the full suite.