I thought it would be fun to share with you how Microsoft came to invest in records management functionality in the 2007 release of our products. I bet that many of you are saying, “It’s about time we got into records management!” and believe me, I’m with you—now. But how we got here is not immediately obvious. We did not have a “master plan” handed down from on high that dictated: “in the next release of the Office System, you will support records management!” Truth be told, it would be a lot easier to build products if we always knew exactly what to build and could just focus on making the best products possible. A big part of our job in program management is to figure that out — to decide what’s important and how much to invest in each area.
How do we determine what’s important? Well, we have a lot of help! Our most important method of research is listening to people like you. But often, customers don’t articulate their needs in clear, black-and-white terms. In fact, hardly anyone said “We need physical and electronic records management” back when we began planning this release. So how did we get here? Our decision to invest in records management came from the culmination of several independent factors that all converged about two-and-a-half years ago. Today, I’ll talk about the first one: Information Rights Management (IRM).
In our 2003 release, my team worked on bringing a brand new technology into the Office family of products: rights management. It is a technology that helps end-users and corporate administrators set rules on documents about how long they can live, which users can open them, and what they can do with them after they’ve been opened. This feature helped to solve scenarios like “Let me send an e-mail that cannot be forwarded on,” or “Let’s keep this document confidential until the end of the fiscal quarter, and also ensure that no printouts are made.” Sounds nothing like records management, right? Right.
Well, we ran into a couple of problems trying to figure out the best way to present this feature. The technology itself uses encryption to ensure that people who don’t have permission can’t open a document. By itself, this would make IRM a “document security” feature. The problem was: we couldn’t call it “security.” Why? Because once a person has permission to open a file, even if they’ve only been given “read-only permission,” they could behave maliciously and take a digital camera photo of the screen, retype the entire document, or read the contents into a personal audio recorder. That’s not end-to-end security! (Particularly when a few years ago, security was the buzzword and the most sensitive topic in the industry). So, we altered our messaging slightly: We decided to describe IRM as a “policy enforcement feature” and not a “security feature.”
Unfortunately, this categorization of the feature got us a couple of hard knocks… it’s also one of the factors that ultimately also led us to records management! With rights management, when an author decides that a given document is sensitive, they select who should have permission to the document and what the recipients can do with it. But, to open a document the very first time, a recipient would have to get an access license from a rights management server that unlocked the document’s encryption. Our rights management server could be set up to “audit” all access license requests. We also had a neat feature called “expiration,” which prevented a document from being opened after it hit a given date.
In the process of talking to customers, we found ourselves frequently getting the same hard questions… none of which made sense at the time:
Question: So, when a user reads a document, can that be audited? Would that help me achieve CFR 21 Part 11 compliance?
Answer: Not really. The auditing wasn’t intended to track every kind usage from every user, just the initial request to read the document…
Question: This “expiration” feature… can I use that to destroy documents everywhere that they live on a specific date?
Answer: Not really. The expiration feature prevents the document from being opened on a user’s desktop, but the corporation still has the keys to open the document in the event of a litigation or audit. So, it doesn’t really “destroy” the document—it just prevents users from opening it.
General Response: Huh?! That’s not a very good “policy enforcement” system!
For a while, this bothered us quite a bit. Had we just built the wrong thing? We had cool scenarios that customers told us they wanted, and yet we kept getting told that IRM was not a good “policy enforcement” feature. What was it that our customers were really looking for?
When we finally figured it out, it was obvious: our customers were looking for records management and compliance features! We were getting asked these questions by individuals that were responsible for the governance of documents within their companies. They were looking for solutions to really hard problems, like how do I keep an audit trail of everything any user ever does to a set of documents, or how do I limit my legal liability by disposing of documents in a timely and consistent fashion? IRM was not the “silver bullet” they were looking for. What they wanted was something a bit different.
Of course, it took us a while to figure this out. Meanwhile, we were hearing a very different story from a different part of the industry. Early next week, my colleague Ethan will take a look at what was making headlines just a few short years back…
Jason Cahill, Lead Program Manager