In part one of this two-part series on corporate memory, we defined what corporate memory is, why it is important and provided some examples of sources for it. Let's discuss for a moment a rather worrisome aspect of corporate memory: memory loss.
Corporate memory loss
Part one of this series included examples of how corporate memory can be lost. People forget, retire or just leave the company. Paper documents are destroyed or lost. We now have plenty of choices of systems to deal with these potential problems.
But there is a bigger problem lurking. What happens if the systems we used to capture our corporate memory are no longer there? Are we responsible for handling that, or do we just say “it was ancient history, and we don't need to keep it”? How far back do we need to preserve?
We can categorize the issues this way:
- Old software and documents which cannot be opened. Examples are productivity applications: What about documents that were created in old software that is no longer available? What about documents that are stored on media that will not work on modern computers like, for example, floppy disks or jaz drives? (I'm testing your age here)
- Software that worked fine but eventually fell out of favor. Lotus Notes was once the premier solution to capture and store information. Many companies migrated data from Lotus Notes to other systems as they discontinued its use, and many did not. A few companies still actually have a running version of Lotus Notes somewhere just so that they can access the old corporate memory. How long will it continue to work? Lotus Notes is just one example. There are many more.
- Software companies that went under. There are probably too many examples to list here. Hopefully, the information from that software was able to be extracted before it disappeared. In the early days of Sopheon's existence, we had a competitor who was in the market before us, but their software did not scale and they went out of business. We helped some of their customers (who became our customers) migrate over to our Accolade innovation management software. But something like that is rather rare.
- Choices to move from one software to another. This is very common. We use an application for many years and build up a significant amount of corporate memory in it. Then, we decide to move away from it in favor of another application. We make choices about what happens to the older corporate memory. We decide if the old information needs to be migrated to the new application. Sometimes, the cost of migrating information is too great. Too often we make that investment decision only based on the current cost estimate being presented to us and we do not, or are not able to, consider the value or importance of the information that will not be migrated due the cost to do so.
Lastly, consider generational culture. Earlier generations wrote everything down, often in great detail. Current generations, not so much. Do we still care about remembering decisions from the past? How far back is it important to us? How much longer will we still care about the past? Is this changing with each generation?
Innovation-related corporate memory
Now let's look at corporate memory related to innovation. Here are some examples:
- Product decisions – what decisions were made about a specific product, who made them, and why?
- Product designs
- Product tests
- Consumer feedback
- Product development and introduction processes (sometimes the process is as important as the data)
- Certifications
- Approvals
- Discussions (an important source of corporate memory that is often overlooked!)
- Projects
- People
- Competitors
- Business or strategic decisions – who made a business decision (for example a decision to invest in a given market or given type of product line) and what did they know when they made it?
What's so special about innovation corporate memory? Well, for one, it tends to be neglected. Financial records are the most secure in a company. Not so with innovation.
And yet innovation is much more related to, and dependent, on history. We don't want to reinvent the wheel or to fail because we forgot something important from our past. And we want to take advantage of opportunities today that were rooted in the past but perhaps not pursued because conditions were not right at the time. We may have had some great ideas that were not feasible back then, but would be blockbusters if brought out today.
Perhaps more importantly, we need to get away from tribal knowledge and engage all employees in innovation, especially newer employees with new ideas. Isaac Newton said in 1675, "If I have seen further it is by standing on the shoulders of Giants.” This is the kind of innovation we want!
Agile stories are not enough
Consider the software world. At one point design documents were a key component of the software lifecycle process. We had:
- systems design documents,
- product requirement documents, and
- market requirement documents
These were often large documents with a wealth of information in them. When software development shifted over to the Agile methodology, some of these disappeared and were replaced with Epics and Stories. And we found software that was particularly good at capturing and organizing the Epics and Stories in a database format. We moved away from large word documents and broke them into small pieces that were linked to each other.
The mountain of linked documents has become a mountain of stories. But often times the stories are not as connected together as the sentences and paragraphs inside the documents were. They are more discrete, intended to be prioritized and shuffled across sprints and releases.
As we have moved forward down the agile path, too often the stories have become more about “what” and less about “why”. The “why” has become focused on the user rather than the business rationale. We write “as a user I want to…” and do not address the importance from a business strategy or a competitive point of view. Epics do a better job, as do Lean Canvases, but still often miss the mark from a long-term perspective.
These aspects of corporate memory are not lost, but rather we have chosen to not capture them in the first place. Time will tell if this has been a good idea or not.
Did we develop something to be new to the world or first to market? Was it because of a competitor? Did we need to prove something to the market or to ourselves? Were we sure about something, or were we testing our assumptions? What was our strategy as a company, and how did we support or enable that strategy with our software?
Often, the answers to these questions are not captured.
What about financial assumptions and expectations? Again, this is often not captured.
Beyond software and into smart products
All of the software-related corporate memory aspects we just discussed exist but are often amplified when the software is embedded in smart products. Smart products merge the physical and digital capabilities, and often times have more need to capture and preserve the relevant corporate memory.
For the physical side of smart product innovation, we need to capture and be able to recollect why we designed something the way that we did. For example, why we used a particular chemical, or why we selected a particular formulation and what the limiting factors were.
Further, smart products are subject to different types of regulations and certifications. Also, smart products have to consider potentially costly and brand-damaging recalls.
Each of these aspects can magnify why retention of corporate memory is essential and how it might be different for smart products as opposed to other types of products.
Conclusion
Corporate memory is an essential aspect of product innovation. Careful consideration is needed about what should be recorded and for how long. Here are a few suggestions to get you started:
- Use some of the topics and aspects written about in this series to identify your particular needs and your approach to corporate memory.
- Assess your vulnerabilities. Are you a regulated industry? Is your business volatile? Do you have a lot of employee turnover?
- Make an assessment and categorize corporate memory into buckets: critical to retain, important, not important.
- Document your sources of corporate memory – who is generating it and how often?
- Conduct a risk assessment around losing corporate memory.
- Document your repositories.
- Conduct an architecture and systems assessment of your repositories
- Include your IT department in the analysis.
