Personal Information Lifecycle Managemenet

My company is currently re-launching its knowledge management environment, so I thought it would be useful to re-think my requirements from a personal and then (in another blog post) from a team/project perspective. The diagram on the left represents a simplified view of the personal information management lifecycle and I will step through each phase looking at the commodity tools that I think all knowledge workers should have, by right, in todays world.  Then I will discuss some of the more advanced tools that may only be applicable to certain high value processes or industry segments.  First off I make no apologies for the simple model I have chosen to use.  More complete lifecycles have been modelled, for example this one by David Pollard which is a more comprehensive view of the creative process, and if you want to dig deeper go read his work as it’s better than mine!  However I wanted something that was visually simple and easy for people to relate to.

I will be testing my companies project against the content of this post,  it should be interesting!

First off lets deal with the coloured groups,  the green octagons (subscribe, search and discuss) are ongoing activities for any knowledge worker who needs to maintain their subject matter expertise.  The blue octagons (organise, innovate and create) represent the directed activities of an individual or team trying to achieve a goal.  The red octagons (review and publish) represent activities that relate to a broader community than those undertaking the directed act of creation.  The collaboration octagon at the centre represents the fact that everyone needs to collaborate throughout the whole information management lifecycle, although the tools and techniques will differ depending on whether the collaboration objective is:

• Co-development
• Co-ordination
• Co-decision
• Commitment

The rest of this post will step through the lifecycle “octagon by octagon”:

No new system should ever be deployed that does not have an effective mechanism for people to subscribe to change and aggregate change information that arrives from many different information sources.  Knowledge management projects must realise that no matter now effective they are; knowledge workers will still need to aggregate subscriptions from many different sources both inside and outside the enterprise.  The de-facto standard today for subscription and aggregation is RSS.   I will stress again that this applies to ALL systems from team workspaces, to risk registers to change logs to company news feeds.  Web sites on the Internet are learning this lesson fast and all news sites have probably already learnt it or are dying.  It is no longer acceptable for any information provider to assume that people will pro-actively go to their web site and “look for changes”, nor is an email summary of changes an alternative.  For repositories that contain documents or other media files enclosure support is encouraged.  This naturally means that employees need access to an RSS reader, although it’s difficult to believe that information workers will not already have discovered the need already.  It’s a fortunate coincidence that subscription comes first on my list because it’s probably THE most fundamental commodity requirement.  I have discussed my personal use and ideas around the use of subscription in several blog articles that you can find here.

Although subscription is often the trigger for maintaining subject matter expertise search is still fundamental to exploring and extending expertise based on the subscription trigger.  Of course the main source of information continues to be the public web and (for IT stuff) analyst web sites.  However effective Intranet search is still important, in my view context sensitive searching is also important, ie the ability to search just within repository but also across repositories, and of course not forgetting desktop search.  Whatever search solution is deployed navigating the results set is made much simpler with a tabbed browser designed for the task, and without comparison for this task I recommend Maxthon, for the following key reasons:

• It allows bulk opening of tabs in the background
• It allows bulk closing of tabs, (all, all to the right, all to the left)
• It allows a set of tabs (ie web pages) to be saved as a group for later review.  In my case I am currently collecting groups of pages that refer to interesting articles on Innovation and SOA, as well as archiving off all of the memorable pages I read each day.

I am a strong believer in exposing ones thought processes, especially decision making processes to the relevant community and there is no better way of doing that than through mechanisms that encourage discussion.  The mechanism for discussion used will depend on the phase of the activity, during this phase – maintaining subject matter expertise – the blog/comment model seems to be the best option.  So any knowledge management solution needs some mechanism to allow people to maintain a personal journal of their evolving subject matter expertise which others can subscribe to via RSS and comment on so that the subject matter expertise of the community evolves as well.  In high value areas its probably worth considering maintaining a journal for the area of subject matter expertise that either automatically or manually aggregates the (most important) content from the SME journals.  This agregated journal can then provide a more focussed area for discussion.  What is absolutely key is that most if not all content that is published needs to be comment enabled,  a “discussion area” is not what is intended in this post. I have discussed the importance of journals in my blog in this post.

The previous activities relate to maintenance of subject matter expertise,  the next set are directed activities towards some objective, most often in the form of a project.

I am using a broad definition of organise, but in general terms it includes the following main activities.  The formulation of an objective and the requirements/goals and tasks to it.  Information gathered during the previous (green) phase is Marshalled and organised, shared with other team members etc.  The activities that need to be undertaken are broken down into activities, with dependencies.  Progress is measured in terms of key milestones, preferably ones that demonstrate measurable progress towards the achievement of the requirements/goals, and not just expended effort.  During this phase much discussion and debate will take place around key deliverables such as project definitions, requirement definitions, resources, costs and time scales.  The ability to maintain a journal during this process can greatly assist in the process of keeping the team committed and coordinated.  I have discussed this in this post.  During this phase it is important to confront the issue of how well your customer represents your users; and especially for IT infrastructure project whether they understand their own requirements.  This important issue is discussed here.

During the organising phase and thereafter assets that are referenced during the definition and execution phases of the project should be captured and should be available as referenced supporting evidence.  Personal information management tools that provide this level of formality include products like NetSnippets and Onfolio.  Repository designers should ensure that enterprise versions of these capabilities are available or build the publishing processes/capabilities of these personal tools into their knowledge management processes, and should choose a corporate standard to facilitate sharing on this information within project teams.

It is often during this process that negotiations are being undertaken,  high fidelity video conferencing can be important during this phase to ensure that the maximum level of commitment is achieved between team members, managers and customers.

It is likely that any new project will involve a process of innovation.  This topic is discussed elsewhere in my blog but basically involves the following key processes:

 

• Carefully stating the need, preferably in generic/conceptual terms
• Surveying of existing solution options to address the conceptual problem
• Idea generation and filtering

Formal methods such as TRIZ can add considerable value in this process.  However tool supported implementations of TRIZ may only be affordable for major projects. For many projects applying the TRIZ problem modelling approach (positive and negative factors) can still add value.  Low cost and easy to visualise mapping techniques can complement TRIZ as shown here.

Regardless of the existing assets identified during the previous stages there will still be the need to create some new deliverables from an activity.  In many IT projects this project of co-development will require the full armoury of synchronous and asynchronous collaboration tools and well as the use of journals and subscription to project document repositories, risk and issue registers and change logs.  In addition the project team will greatly benefit from prototyping and so far as is practical trialing the delivered processes and tools them selves and not just relying on formal testing.  This process is often referred to as “eating your own dog food” and its application to systems integration projects is discussed in my previous work on the subject, here and here.  Anyone producing written deliverables – reports – should look to these tips on how to write a good report.

Designers of a knowledge repository should as a minimum ensure that it provides journals, version controlled libraries, project announcements and risk, issue and change logs, that are all comment and subscription enabled.  For inspiration they should look to collaborative authoring technologies like wikki’s.

Development teams that are fortunate enough to be co-located should make sure they take advantage of their workspace, some tips on how to do this are provided here.

Review is NOT an activity that takes place on completion of deliverables,  for project team members and other stake-holders review should have been intrinsically part of the development process, most often in the following ways:

 

• The development should be reviewed at key milestones, that represent key progress through the project lifecycle.  Sometimes it’s sufficient to describe these in terms of progression through the conceptual, logical and physical design phases.  However my preference is to phrase the review criteria in terms of key stake-holders signing off that their requirements are being satisfied, for example the customer agreeing that the functional specification and prototype meet their requirements, or the service delivery organisation signing off on organisation changes and staffing levels and training needs etc.  In addition lead architects and engineers should be reviewing the decision making process as it progresses, understanding the range of solution options and how these have been refined and chosen.  Again Journals can have a significant role to play in this.
• Reviews should be designed into the programme plan, along with the key deliverables that are required in order for that review to proceed.

Repository designers need to ensure that deliverable status can be easily tracked, commented upon and that changes can be subscribed to.  In addition it should be easy to define sets of deliverables that make up a release, or that are required to achieve a particular milestone.  Finally the repository should make it easy to design and execute the formal review and approval workflow process.

Deliverables are ultimately published, ideally in a long life format and referenceable by a persistent URL.  New published deliverables should of course then be available to support the subscription and search elements of the lifecycle that this document began with.  Repository designers should also look for products that automatically generate PDF renditions of deliverables that are maintained and linked to their native master documents.  ideally published deliverables should be populated with meta-data that can be used by search engines to improve accuracy of results.

I will be discussing collaboration in a separate paper as whilst elements of the collaboration activity have been described in this document full consideration of a subject of this importance demands that collaboration is decomposed into the elements:

• Co-development
• Co-ordination
• Co-decision
• Commitment

with each discussed in some detail.  In addition higher value processes like idea management and innovation management will be included as will the issue of how to support the myriad of business processes that knowledge workers find themselves having to navigate, with little or no tool support, improvement metrics and in some cases even without documentation.