While it's true the industry is changing and that workplaces are becoming more social, collaborative and interactive, it's also true that it's hard to teach an old dog new tricks!
And, if the rate at which I can complete things depends on my ability to memorize a folder structure, once I have it memorized, why would I want it to change?
I've recently been consulting with a great team that has been developing a SharePoint 2013 site as a way for their team to communicate together. They are looking for ways that SharePoint can help them do their simple day to day activities in a more efficient and consistent manner.
The team spends a great deal of time referencing previous content and using that to build new content. This particular team has to work together very quickly, under tight deadlines and must be ready to respond to any non-standard requests. The team recognized that there are many tools within SharePoint that can assist them, but getting started has proven to be a little tricky for them.
For years they have been using a folder structure and by memorizing common tasks, the team can function fairly well locating and finding the content that they need. They know that to expand their team and be able to focus on different aspects of their roles, they will need to restructure how they are doing things. But how does a group of users rethink years of working in a specific way and come up with new ideas on how to work differently? In this article we are going to look at this concept in more detail and present some various ideas that can be used as a starting point when you face similar situations.
Think Big, Start Small - Keep Growing
The first point that I want to cover is the importance of thinking big, but starting small. There is great benefit in looking at the big picture and imagining all the various elements that can be included in your solution. Many times these will come from the statements of “wouldn't it be great if …”
Thinking at this level allows you to step away from the present and into an ideal future. But the danger in thinking big but not starting small is that you can bite off more than you can chew, or worse yet, you could be so overwhelmed with the changes that you never get started! I run into this a lot when I consult with people who feel like they have great ideas, but that they lack the skills required to build the solution. There is no way that you can know all the skills needed to build any solution within SharePoint all at once, and anyone who claims to know it all really doesn't.
But just because you aren't an expert in the tool, doesn't mean that you should let that limit your use of the tool. If you start with the basics, you can advance to more detailed and complex items over time, when you are comfortable and ready. But if you never start, you will be missing out on many benefits.
In this particular scenario the team started thinking big by envisioning a single location to manage all of their content, store templates, email notifications and then serve as a searchable repository so that they can easily reference anything from the past. They started small by creating a few libraries and moving content to those libraries. This allowed them to achieve the first step of moving their content to a single location. Because of the quick response time needed for requests, this approach was the least disruptive for the team.
Keep in mind that each organization is unique and each team within is going to act and work differently. This means that the approach I described above may not be the path that works best for you. The point I want to be sure to convey is that you have to start somewhere, so no matter how your team works, there is value in finding your big and defining your small.
Once you get started, the next thing to look at is how to keep growing. This will be different for each group and solution and can depend on many internal factors. But using this phased approach will allow for continual value to be added to the organization through your solution.
For the team mentioned above, this step has been the hardest. They can see the ideal state and they can see the first steps, but how do they make the middle more clear? One of the issues at the forefront of our discussions is how do we go from a collection of libraries with a large folder structure, to a more streamlined organization structure that would allow for any new team members to step into the group without having to memorize a complex file structure?
Everyone agrees that this is likely the best next step, but how do we go from something that “works” to something that might be better? This is a common scenario that I run into with various groups and it requires that we think about things differently. Instead of focusing on the technology and how to transition from one technology to the other, we instead need to think about the business and how we can apply technology to compliment the business at hand.
No Technology Zone
Sometimes I think the best way to force the conversation away from technology and back to the business is to remove all technical talk from the meetings. This can be a hard task at first, but I think that you will see in the long run the value of using this approach. At the end of the day the most common IT terms are still defined differently by almost everyone in the room. The best way to ensure that everyone is on the same page is to simply remove the terms and only speak in business terms.
This also brings the conversation back to a level that everyone in the room is comfortable with. While everyone on the team may not understand what columns I need in a document library, they will understand the need to reference data based on the year it was published or by the client it is associated with.
This is one of the small things that can make a big impact on how you map out your solutions. Once you have clearly mapped out and discussed the components and how they are required to behave within the solution you can match that with the technology. This is a great point to bring in as a consultant or even an opportunity to increase your internal skill set. This is also the point where you can determine the best way to complete the task at hand. I like to say that often there are a million ways to do something in SharePoint and none of them are wrong! If we move too quickly and start with the technical components we may work ourselves into a corner because of the way we chose to implement something. Instead it would be best to have it all clearly defined and then move from there to the technical approach.
Understand the Users and the Roles
When you start to look at the process, you should be able to identify the various users with access and once they are involved, what their specific role is in the process. Having this separated allows for you to clearly identify if all users and roles behave the same. If they do, then a single solution will work across all roles. If they all have different perspectives and different needs you may run into issues if you try to build a “one size fits all” solution.
If you end up in a scenario with various users and roles then your final solution may end up including some role-based components that help push the most relevant information to specific users. By defining these users and roles during the planning process you can help guide the conversation with the group. If team members can’t agree on the process being discussed and what needs to happen it could simply be that they are viewing the process from one perspective over another. By clearly having these outlined from the start you can refer back to them and use it to guide the conversation about the process and the business requirements.
The Blank Slate
Another approach to looking at the problem differently, apart from the technology, is to have the team look at it from a blank slate perspective. If you were creating a new department or group that had the same job as yours, but with a completely blank slate, how would you structure the solution? Using this approach allows you to step away from all of the past and helps separate the new solution from the ideas of “this is how we have done things in the past.”
Typically when you use this approach you start the planning and discussions as if there isn't any existing content that needs to be migrated to the new solutions. You instead work on designing the ideal solution and once completed you review your current state and look at ways that you can move from the current state to the ideal state. Part of this process may include making changes to the ideal state to accommodate limitations in the current, but it is better to do this after you have mapped out your ideas so that you can be sure you aren’t letting any of your limitations impact your solution design.
One final approach I suggest to various teams is to use the mockup approach. In this approach I tell teams to go to a whiteboard, napkin, Visio or Word (whatever tool works) and draw out what the ideal solution for their problems would look like. I typically have multiple users do this and then come together to discuss.
Using this approach speaks well to the people on the team that think visually and allows them to visually represent what they see as ideal. It is said that a picture is worth a thousand words, and when it comes to understanding the needs of the business this can be a great truth. Once you have a visual representation you can discuss the elements included and use that as a starting point to clearly define the needs of the solution.
In closing, the best advice that I can give is to try a variety of things to help your users as they try to map out and plan what their solutions can be. In our scenario we want to really focus on what they know best -- the business. This allows us to save the technology for later and really get to the heart of what would make the team work better. The technology can always be applied to the proper business problem, but applying technology to a non-defined problem is only going to make a bigger problem.
These approaches have been ones that I've used over the years within many different groups as we looked at ways to help them get more from SharePoint. I hope these ideas will help you think through how you approach building out your solutions and will remind you that it’s all about the business. By staying focused on the business and on solving the right business problem you will help ensure you are starting in the right place.
Title image courtesy of cynoclub (Shutterstock)
Editor's Note: Read more from Jennifer in Driving User Behavior within Your SharePoint Solutions