Inventory Analysis and Information Architecture Jumpstart
During my SPBiz Conference session today, I fielded a couple questions about two of the most important aspects of the pre-migration planning effort: your inventory analysis and your information architecture. The two really go hand-in-hand, and I would consider info architecture an important part of your overall inventory analysis. The guidance I provided was fairly simple: if you do not have an accurate assessment of what you have in place today, you will not be able to accurately plan your migration. While inside of Microsoft and performing internal migrations (the early days of the Office 365 team), we would casually ask teams about the degree to which they had modified their environments, and then sort of try and force-fit whatever structure and content was in the old system into the new platform. And this method failed a lot. I mean, a ton. So when Microsoft provides guidance about how to organize and orchestrate your migration, believe me, they’re speaking from experience. They’ve taken all the wrong turns, tried to rush things through without proper planning. So we need to learn from their mistakes and follow best practices.
The larger topic, however, is less about your current migration effort – but about how you are managing your current platform, and how you will manage your future platform. That’s right – inventory analysis and information architecture, at their root, are really a governance topic. If you have solid governance mechanisms in place, guiding how you manage your environment, your pre-migration planning should go relatively smoothly.
The question I hear the most is: How do you begin? We all know SharePoint’s history of being “unleashed” on our teams without proper planning or governance structures, and most administrators find themselves needing to retroactively apply standards across their environment. Companies tend to hoard information and may find themselves overwhelmed by the disorganization, and how to even begin the process of identifying what is there – much less to get things under control.
The reality is that for most of you, your SharePoint environments are a governance wreck. And unfortunately, there is no easy-button fix. You’re going to need to dig in an get your hands dirty, and yes, talk to your end users. A lot. Because they know their content better than anyone, and they are your best bet to jumpstart your efforts as you look to put in place a more formal governance model:
- Create an internal SharePoint user group
This is pretty fundamental. You need to tap into the community as a way to refine your model, adapt your systems to the ebb and flow of the business, and, quite simply, to learn from your users. I’d suggest creating both a task force with accountability for defining your inventory and prioritizing what they find. Yes, most 3rd party tools provide pre-migration reporting. But you need someone to sort through the reports and prioritize what they find. As part of your process, have the task force present their results to the user group before finalizing your plans. By allowing users to participate in and define the priorities, the users will have a vested interest in the success of the system. - Clearly define roles and responsibilities
Governance Task Force chair and members. Administrators. Project Owners. Approvers. Reviewers. Identifying core permissions and groups within SharePoint is one aspect, but modeling your governance model on your internal project methodology makes sense. If you don’t have a defined methodology, just keep it simple. Err on the side of ad hoc flexibility over rigid structure, as it is easier to add structure as needed than to remove it. At Microsoft, I was a fan of the OARP model: Owner, Approver, Reviewer, Participant. It was simple and clear (when it was used). At the very least, you should understand and assign similar roles within your organization so that it is evident where accountability resides. - Create a plan, then iterate
Once again, this is the most difficult aspect of governance for most organizations: putting pen to paper and outlining your plan. The point here is to create something, get feedback, and iterate. By taking it in small steps, it allows you to step back and reflect after each iteration. You’ll be amazed at quickly things will then come together, and with everyone participating, your governance strategy will more closely reflect the way your users work, and the way your business is actually run. But remember: this is just a start. Your governance task force should perform a regular review (monthly/quarterly) of your information architecture, sharing proposed changes with the community and incorporating feedback.
I know this post feels very rushed, and I’m just scratching the surface of some huge topics. I started talking about migration, brought up inventory analysis and information architecture, and then landed on governance. Believe me, they’re all connected. The actual migration effort is the easiest part of all of this – but its only easy if you take the time to inventory your systems, prioritize what is there, work with your end users to develop (or modify) your information architecture, establish some governance best practices, and then put a plan in place for the actual move.
My advice: keep it simple, let your processes grow and develop organically, and keep your users in the loop on what you’re thinking and doing. These things will go a long way in ensuring your SharePoint deployment is successful (i.e. people are using it!)
