OffiSync + Google "Cloud" (e.g., Docs, Sites) + Google SaaS (Apps) + MS Word

OffiSync - the short story: Just go to the links below:

• Website: OffiSync
• Video: Using Google Docs with Microsoft Office and OffiSync
• Video: Using Google Sites with Microsoft Office and OffiSync
• Video: Co-Authoring with Microsoft Office with OffiSync

The background:

Over the years I have done a lot of work in documentation, and two things stood out as being very useful in that work:

• Microsoft Word (MSW)
• Microsoft SharePoint (MSS)

• MSW (for "Microsoft Word"):Since 1998 my dependence on MSW has grown. Then, I had to embark on a journey to become a "power user" of MSW, when faced with some major documentation tasks on a large and complex documentation project. I initially read "Taking Word for Windows to the Edge" from cover to cover, to begin that journey. Over the years, MSW has been continually refined and improved by Microsoft. It is an amazingly powerful document creation/editing tool - though sometimes I still miss the power of the Macintosh's Adobe Pagemaker (I think that was it's name) from the '80s.

• MSS (for "Microsoft SharePoint"): I originally became involved in MSS through managing the installation of a SharePoint site for a client, and later in using SharePoint sites as document repositories and collaboration/workflow tools. MSS is a powerful document management and collaboration tool, and integrates beautifully with Microsoft products IE and Office, but it is still very much a proprietary tool.

OffiSync: In 2009 I installed a Microsoft Office Add-In called "OffiSync", which enabled me to link to documents in Google Docs. By that stage, Google was clearly setting up to provide cloud-based document management and collaboration that looked set to eventually eclipse SharePoint.
When I installed OffiSync, I was very impressed at how it aimed to tie Microsoft Office into the Google Apps/Cloud. Up until now, however, I have used it only a little, as it seemed a bit slow/kludgy. I was in "Wait and see mode".

Looks like my waiting is over. Whilst Google's increasing range of cloud-based apps/services was itself disruptive and made for some very useful services, it seemed to me that OffiSync built on that range in such a way that it could potentially be a tremendously productive step forwards.
With Google's updates to Google Docs and more updates to OffiSync, I have to say that this potential now looks like it could be realised.

See for yourself anyway:

• Website: OffiSync
• Video: Using Google Docs with Microsoft Office and OffiSync
• Video: Using Google Sites with Microsoft Office and OffiSync
• Video: Co-Authoring with Microsoft Office with OffiSync

Tip - Defining your Information Management requirements

I was having a discussion in email some time ago, with someone about what their requirements were for information management and I suggested an approach for them to define their requirements. I developed the suggestion further in order to make this post.

To a large extent, the typical approach is for users to take an ad hoc, features-based approach to stating their requirements. That is, looking at the features of an information management system (e.g., Evernote or InfoSelect or Gmail, amongst others) and saying "Look how useful that is" or "I don't like this" (e.g., a "ribbon" menu) or "I do like this" (e.g., the ribbon). This actually is not the most helpful way (to a developer) to go about providing or gathering requirements, since a like or a dislike does not necessarily define a requirement nor does it necessarily even identify a requirement. This is why attempting to build a requirements list by, for example, a straw pole (likes and dislikes) is usually doomed to failure. It is, in fact, irrational.

As WE Deming said, "Action that is not based on sound theory or best practice is irrational by definition".

The requirements-based approach, on the other hand, basically says "This is how and why I want an information management system to work for me", and it does not concern itself with features or how the system is to work (the latter is the developer's domain).

What I would therefore recommend is that, if you have not already done so, then take a leaf out of the Kepner-Tregoe approach (an approach to rational management) and use a 3-column table:

• in column 1, write down a list of these things that you want to be able to do (requirements);
• in column 2, write down against each item in the list why you want to be able to do that thing (i.e., what is the purpose of that requirement?).
• in column 3, write down the appropriate priority - A or B or C - for each requirement, where:
  * A = Mandatory ("must have").
  * B = Highly desirable.
  * C = Nice-to-have.

This approach is the one I usually take for myself and (in the role of an IT and management consultant) one that I often recommend for my clients.

The act of drawing up your requirements like this can be quite useful, because usually it means that:

1. you will be able to more clearly understand your own information management requirements as a whole (there they all are, in front of you, in the 3-column table).
2. you will be able to more clearly articulate those requirements (they will have been defined).
3. you will be able to more easily communicate those requirements (because they will be clearly articulated).
4. the rationale will be clear: the requirements will have been identified in a consistent and rational manner (as opposed to being thrown out in an ad hoc manner with little or no substantiation).

As a spin-off, you also might discover something about your requirements and their purposes that you might not have previously appreciated (i.e., not been fully aware of or understood).

Once you have such a requirements list, then you could - for example - give it to the developers of (say) Gmail or InfoSelect or Evernote, or people who might be able to suggest ways of meeting the requirements using the available desktop + cloud technologies.

If your requirements grow or change - as invariably happens - then you update the table to reflect the changes. That way you maintain a current and consistent picture of your requirements and will not have to dream it up (and inadvertently forget some) each time someone asks you.

There are some further - and interesting - points about the requirements list which is probably worth mentioning here:

(a) By taking the steps (as above) to build the list, the user is effectively taking responsibility for defining what it is that they want do (the requirements), and why (purpose), and how important (priority) those requirements are. If the user furthermore maintains an updated list of those requirements, then they are continuing with that responsibility.

(b) It can be seen therefore, from this, that it is not the developer's responsibility to somehow "know" your requirements by some process of magic, or osmosis, or telepathy. Therefore, berating the developer for not building in some feature that would meet your requirements - where you have not communicated them to him/her in the first place - could be regarded as being irrational.

(c) This is not to absolve the developer of the business responsibility for systematically soliciting and gathering user requirements in a similar manner to that above, and for taking note and acting on those requirements. Nor does it absolve the developer of the responsibility for researching and applying the art of what is possible using new technologies (e.g., "cloud" computing) that could be incorporated into the system to better meet the users' evolving (and defined) requirements. Failure to do these things will probably run the very real risk of product obsolescence.