If you build things in SharePoint often enough, you are going to have to answer the question we were asking ourselves this week – how close to real do you make a prototype? Personally, I have never liked the idea of building a prototype with the thought of turning it into a permanent solution. Build it, learn from it and then build the real thing.
A few days ago, we met with one of our attorneys to discuss a site that we are going to build for official business documents. Some of these would be governance documents like our company Constitution; others would be things like committee meeting minutes, contracts, reinsurance agreements and the like. We were initially tempted to call these “legal” documents, but in reality, they are documents that simply require a lawyer to be involved during creation and revision. That may seem like a bit of irrelevant semantics, but I’ve learned that when lawyers are involved, semantics are never irrelevant. I mention that because it’s also part of the reason I chose to build a make-believe demonstration site, rather than a crude working example.
Instead of Governance, State Filings and Committee Minutes, we created Jupiter, Saturn, Earth, Venus and Mercury. We grouped Earth, Venus and Mercury into a Quick Launch heading called “Inner Planets” to show that we wouldn’t need a mile-high Quick Launch bar that listed every single committee that might ever hold a meeting and create minutes. We gave every planet a site-metadata column called “Current Version” and we gave them all at least one unique column of metadata. For example, we know that State Filings will be organized by state, so we made sure one of libraries had a state choice column. We populated every library with enough sample documents to set all the parts in motion. Once we showed the attorney the libraries, the kinds of metadata we could build, the way we could build web parts and workflows that used that metadata, he came up with several ideas, including:
A sub site to support collaboration on documents like State Filings. This will have libraries where lawyers and other experts will store everything they encounter and use during the draft and review process, as well as lists and calendars to aid the process.
A document library in the Official Business Documents site where they will store the final version, or perhaps the major versions of deliverable documents, as well as all the supporting documents they feel are relevant in a Document Set.
A records library in which a workflow will create a PDF copy of the final deliverable document.
All of the libraries will be accessible from a parent site home page, which will include a few web parts. One of those will be a list of every document which has been declared to be the “current version.” Another web part will show the documents that have been declared to be records.
The attorney came up with the the idea of a temporary place to build the final documents, a workshop, as it were, designed to facilitate the process and from which they would have to choose what to keep. It’s important to note that:
1) The lawyer would never have been able to suggest his solutions if he hadn’t seen working examples of a document set, a library, a workflow creating a PDF and a web part aggregating content of a certain type from disparate libraries.
2) My team would never have suggested a separate collaborative site because we didn’t really understand the process associated with creating or revising these documents.
Could we have done a bunch of up-front analysis, conducted interviews and designed a site that almost met their needs? Of course we could have. Could we have done that in 90 minutes? No way! Not even if you include the 90 minutes we spent building the demonstration site.
In order to get as far as we did, in such a short amount of time, we needed to quickly educate our attorney and jump start his imagination. Once he understood what was possible, he quickly rattled off our requirements. We all agreed that this would have been harder if we had started out working with a draft business document site. We may have not included examples of all the features he ultimately liked. He may have been reluctant to suggest changes to what appeared to be a nearly finished product and we surely would have dropped into discussions about how we misused the terms.
Next week, I am going to highlight the tools we used to build this demonstration site so fast.