Tag: <span>MSDN</span>

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.

Tech Work

Deliverables are dead. Long live multi-format, anytime, anywhere delivery of information!

The more I think about it, the more I am beginning to see that creating content, writing and styling and planning, for “print” is no longer valid.

Quick caveat: Know your audience and the requirements. Many places mandate printed documentation in one format or another. I am purely talking about my own experience in a software environment.

I’m the first to admit that whenever I start thinking about updating a manual I think in print terms. I think of entire chapters of information, I think of how the user will be able to navigate and understand the layout and construction of the document. Changing those habits is proving hard but I’m slowly getting there.

Part of that change has come about by focussing on the information types we are going to be using as the building blocks of our single source system. Making each topic unique and complete within itself requires some thought and planning, and with that planning being focused on tasks, you soon get a simple outline of the required documentation including the type of information that you’ll be writing for each chunk.

As that realisation begins to sink in, the possibilities of re-use suddenly make themselves clear. It becomes a simple matter of drag and drop to create an entirely new manual, and a new delivery method becomes a simple matter of publishing to a new format.

The latter fits nicely with some current thoughts around how we get our technical information to our customers. Whilst I don’t think Author-IT would be the best solution, or at least the complete solution, I can see us focussing more on a web-based delivery of information, pulling other available content (from mailing lists and wiki pages) into an MSDN-like community website. Add in a blog and some interaction and it could very well be the shape of things to come.

As I’ve mentioned before, for a lot of people in the software industry, the internet is THE source of information. So rather than try and force how we want the information to be delivered (maintaining legacy documentation) I’m looking at how we can deliver something our customers will use, without succumbing to the Web 2.0 crazies. Yes it could have a blog, but does it need one? Yes we could use Twitter to provide ‘from the floor’ thoughts from the development group but who would sanitise them first!

Wikifying the doc set (to borrow a phrase) is a possibility of course, but that would only be part of this solution, and would have to include the ability to package it up as a different deliverable (PDF for example) so the information can be accessed when the internet isn’t available, a requirement of our documentation.

There are other considerations of course, all of which are still being thought through and will need discussion and buy-in.

Exciting times ahead I think. More on this as it develops.

Work