Tag: IPMM

bookmark_borderSharepoint and the IPMM

Posted on

I’m currently part of a cross company initiative (started at the grassroot level) that is aiming at improving our product based information, making the messaging more consistent and ensuring that our customers hear get the information they need, at the time they need it. This is from Marketing down through Sales and into the product documentation itself.

Everyone involved understands the benefits and can see the potential we have if we take this approach. Ultimately it should decrease the information silos across the company and make sure that duplicate content is kept to a minimum. It’s fair to say that, at present, our company is at Level One (with Level Two pretensions) on the Information Process Maturity Model:

“Information developers work independently, designing and developing their content in isolation from other developers in their organization.”

The common aim (and at this point I’ll point out that I’ve not mentioned the IPMM to anyone else yet, but have had it in my head as I helped start the initiative) is to get to Level Three which seems like a good place on which we can build further in the future. Level Three states:

“Information developers are encouraged to form teams to plan, design, and develop content regarding the same product or process. Opportunities for sharing content among deliverables increases because developers are more aware of the content being created by their colleagues. Developers frequently form self-organized teams to jointly produce a result.”

The good news is that, purely because some of us are already talking about the product information, there are other people starting to consider doing the same for other areas of information.

However there is something that will block us and that is the age old problem of document management, and yes the title of this post hints at what we are considering using to help us solve that problem.

The nature of the information we will be producing is very document-centric as a lot of it is written with mind to handing it to a (potential) customer. Currently there is likely to be a small group of people who will be authoring the content, and we had considered using our SVN repository to provide versioning and access control. We’d then publish the documents to a central location on the network.

Still not ideal but, given the current economic climate, it was a free solution for a grassroots level project and we all agreed it would be better to prove our approach was correct first before going cap in hand to ask for funds for a document management system (there are other reasons we shied away from that solution of course, administration and maintenance being one of them).

Then, by chance the other day, one of my colleagues mentioned that he’d just gotten in new MSDN discs and license and he spotted something called SharePoint and “hey, isn’t that something to do with documents? Can you guys use it at all?”.

After rolling my eyes a little (I thought I’d broken that ‘you are the document guys’ mode of thought already!), I realised that yes I could use it, and that it might well be ideal for our cross company initiative.

And so it is I come to find myself reading up on SharePoint installations, configurations and usage. My first port of call will be Tom Johnson but if anyone else has any good pointers please leave a comment.

I’m not entirely sure if it will meet our needs but, if nothing else, it’ll be good blog fodder. Consider yourself warned.

bookmark_borderConsideration Layer Model

Posted on

As a technical writer, every decision you make is influenced by several discrete things, considerations for either the audience of the information, the process you’ll need to follow to collate and verify the information, and so on. Every decision requires such considerations but is it possible to model these?

Some background first; I don’t revisit my old posts nearly as often as I should and, as there are certain topics that I tackle with the vague idea of covering in greater detail at some point later on, it’s handy when someone else gives me a nudge about an old post (namely, The tool is not important).

That said, such topics are typically the hardest ones to consider, the big picture things that end up with my brain reeling as I try to narrow down this wonderful profession into something digestable without generalising (genericising?) so much that it becomes worthless. Still, that’s never stopped me trying, so I’ll bash on and see what falls out of my head.

My post about how the tool is not important looks at the other areas that need to be consider if you are investigating upgrading or changing your main authoring tool, and was largely prompted by our upcoming move from FrameMaker to Author-it. The post is focussed on tools (obviously) but looking back it only mentions a rather large consideration in passing, namely “focussing discussions on the audience, the expectations”.

Such is the way of things when it comes to Technical Communications, anytime you take a step back you realise that there are many things to consider, all of which impact on one another even though they are distinctly different. The audience requires to have information delivered in a particular format (technical consideration), and in a particular voice (writing theory). They’d also like it structured a certain way (information design) and of course they’d quite like it to be accurate and up-to-date (working practice).

As a manager of a technical communications team, all of these things feature in my thinking almost every day. Anytime something new lands on my desk or a new issue is discovered that needs to be corrected my brain runs through the gamut of considerations trying to figure out how best to tackle the work. The more often this happens the more I look for a model of how best to tackle such things and, as I’ve not really found one, I thought I’d take a bash at creating something myself.

This is a first draft, it is still very crude and is missing a lot of detail but as a starting point I think it might work. The premise is simple enough, for each piece of work undertaken by a typical software technical writer (yes, I’m making some assumptions), there are various items that need to be taken into consideration and these can be broadly broken down into four layers – Audience, Content, Theory, and Tools – and within each layer there are a number categories of consideration.

Rather than try and tackle the entire thing, I’m going to focus on the big pieces first.

The following layers are the broadsweep of the model, and I think most technical communication considerations can be allocated to one of the following;

  • Audience – be it preferences for format and media, scenarios for which they require information, through to a detailed understanding of how they work.
  • Content – the main output needs to be considerate of audience, and as such will be provided in different forms (written, graphical and so on). It also needs to be sourced properly, written, reviewed and published.
  • Theory – depending on where you are on the IPMM, this layer may be thin but it will still exist and covers working practice as well as in-house guidelines. It also covers larger view methodologies such as single source, minimalism in writing and so on.
  • Tools – the lowest layer as it is furthest removed from the user but still has a significant impact as it is directly tied in to the writing process itself.

So, does any of this make sense to anyone? Or is it just me? Over the next few posts I’m aiming to delve a little deeper into each layer, presuming I’ve gotten them correct and we’ll see what lies within.

Consider this very much a work in progress, and feel free to point out my errors. Comments are welcomed.