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.