The idea of lifecycle has been around for some time in information management, but typically it’s been used to refer to the lifecycle of information—i.e. create, manage, retain, dispose, archive, etc. And while this is an important perspective on corporate information, I want to present another way to think about the lifecycle of information: the lifecycle of business entities that the information relates to, e.g. project lifecycle, asset lifecycle, product lifecycle, or customer lifecycle.
These business entities tend to be fundamental to how organizations make money and are core (if not the most core) elements of their value chain. So by using them to structure your approach to information management, you stand a better chance of making information management meaningful to the business and allowing it to drive business-relevant results.
A Real-world Example
A good real-world example is the project lifecycle, because nearly all organizations run significant projects that also happen to be document-intensive.
At most organizations, the typical current state of the project lifecycle is that there are multiple stakeholders from multiple functions, spread across multiple departments (and often geos), using multiple document management systems, or—best case—siloed instances of the same system.
During the project, this causes significant inefficiencies, as stakeholders struggle to find the documents they need to get their project work done. After the project is over, the inefficiencies only increase, as even core project team members will struggle to remember where documents are, which versions were the latest, etc.
Much of this inefficiency can be addressed by organizing documents by project lifecycle (rather than by function, department, or geo). And while this can be done on something as simple as a network file share with a defined folder structure, when you do so with a tool like Microsoft SharePoint, the benefits become accelerated.
You can set up dedicated SharePoint sites per project, so that project-level metadata (e.g. project name, cost center, etc.) can be automatically tagged to the documents users upload to the site. Documents can be created and developed in work in progress (WIP) sites or in document libraries based on department, function, or geo, and then be published to the main project site when they’re complete. And when the project is over, the set of final project deliverables can be retained according to the records schedule and everything else (the drafts, early versions, working docs, etc.) can be jettisoned, making it far easier for someone to find the historic project documents they need without all the junk cluttering things up.
The Final Word
What I’ve sketched here at a high level can be done for all the other key business life cycles, such as asset, customer, product, vendor, etc. And when you do, metrics like downtime related to preventive maintenance at the plant, first-call resolution, and product time to market will be positively impacted—something an exclusive focus on information lifecycle alone can’t deliver.