Second in a series, read the first entry here.
The Big Reveal is dead…long live, the Little Reveal
As I talked about in my first post in the series, most Intranet projects focus on a Big Reveal where the project works towards completion and has a big massive launch with much fanfare. There are a number of reasons for this style of approach. Partially it is due to the main landing page being the starting point for the Intranet, and thus a major focus of effort. Since that landing page is usually comprised of information from multiple lower level sources (news, departmental sites, functional areas, etc.), you have to build out all of those areas to make the entire site work correctly. Hence…to launch the Intranet you have to build it all out before launch.
The question I posed last week was…is this the only way to create an Intranet? The answer is no. Instead of a Big Reveal of the entire site, what if we performed a series of Little Reveals of portions of functionality? What if, instead of ensuring that every aspect of the company was represented, we launched portions of the Intranet as they became available and useful? I call this the Little Reveal methodology. The basic idea is that since the site is made up of a series of components that build upon each other to eventually make a holistic entity…we can actually start to make use of these components before the entire system is completed continually adding new features to the system on a periodic basis.
So, how can we break that cycle? The answer, and the secret to the Little Reveal, is that we need to accept some new concepts as part of our Intranet development process:
- The home page is only a small part of the Intranet
- There is a lot of functionality in the Intranet that is missed in the Top Down Approach
- Continuous Improvement will drive End User Adoption
- Continuous Delivery will become our friend
- The Intranet will be seen (as it always should have) as a living, breathing, constantly changing and improving organism
The home page is only a small part of the Intranet
The focus of most Intranet projects is on the main landing page because it is the "face" of the Intranet. The home page gets the majority of the focus of design in terms of branding, wireframes, high-fidelity comps, and content. When you are spending so much focus on one page in the Intranet, it naturally will come to represent the entirety of the Intranet.
The reality is somewhat different from the perception. When I think back on many Intranet (and Internet) projects that I have participated in, one common misconception is that once the development portion of the project is completed, then the site is ready to "go-live". Unfortunately, that is not the case. It is usually at that point ready for content creation…and that can take some significant time after development is completed. That content has to be created all over the Intranet…in the News Center, in Department or Functional areas, Event Lists, Contact Lists, etc. The Intranet is not alive until the creation of that content. If the first page launched is the main landing page…then the amount of work to make that happen is immense and leads to a Big Reveal mentality. In short, how do we launch the main site, when my news slider that is going to roll up news from ever portion of the company?
Partly the answer is that once we recognize that the home page is only part of the Intranet, we can deploy either a scaled down version of it, or, even better, deploy other functional portions of the Intranet first. Here is a novel concept…what if we deployed SkyDrive Pro first? SkyDrive Pro packs a ton of features and end user empowerment into a package that requires almost nothing to implement in the organization. Do we need a fully-fledged brand? Not really, it can be added later if need be. Do we need a developed Governance Plan that details everything about SharePoint? No, we can do a streamlined one that focuses on personal files. Do we need an enterprise taxonomy, content types, global navigation, or site hierarchy? No, we do not have to have any of those things to deploy SkyDrive Pro. We do not even need a landing page for the Intranet…yet.
Now, we do need to train our users on how to work with SkyDrive Pro, how to share files, how to work with the Activity Feed, etc. That can be quick, hands-on, small group training as we slow roll the deployment of SkyDrive Pro.
Our end users are going to love us…because they are going to see immediate improvements in their lives. Easy personal collaboration, multi-person editing, simple sharing of files, anywhere access and the list goes on and on. The key here is that we have provided them with useful functionality with very little development effort and, much as we do with User Centered Experience, involved them from the start of the project. SkyDrive Pro doesn’t have to be the first thing that we roll, out, but it makes sense due to its ease of implementation and significant increase in functionality. It could instead be a Community of Practice site, or an ad hoc collaboration center, or any number of other quick wins. When we no longer focus on the home page as the first page…the possibilities are endless.
Next time we will talk about how we can miss functionality in a Top Down approach, and how we have to change how we develop to make this work.