The topic of collaboration may seem like old news (it probably is), but having had the privilege of working with different organizations and learning how they define collaboration, how they collaborate, and the tools they are using makes me think there is something more to explore on this topic.
Collaboration isn't as straight forward as one would think. On the surface it is a repository for files powered by the document management benefits that SharePoint has to offer (E.g. version control, custom views, filtering capabilities, search). Even in the same organization, every collaboration space (projects, departments, committees etc.) may be used differently. Sure, there are many best practices out there in terms of how to implement a collaborative solution and there are certainly lots of creative ways to fulfill a requirement, but the interesting parts lies under the hood. The content, structure and level of detail being tracked in these "collaboration" sites highly depend on the things that define what collaboration is - (you may have heard this before) they are the people, processes and tools. For the sake of this article, let's look into the processes a bit more.
Processes drive what we do, why we do it, define who is responsible for what and where the resulting product/deliverable needs to end up.
Short of asking "what is your process" (that is the same as asking "what are your requirements?"), we'll need a better place to start. Behind every process are the people that drive it and the tasks they need to perform.
Let's walk through an example. A Project Manager has asked you for a team site where they can store key project information, project documentation and share them with their team members. After a brief conversation, you have uncovered the following:
- Each project must have a Statement of Work and a Charter
- Meeting minutes are produced at the end of each meeting
- Status reports and project plans are updated regularly and shared with the client
- Issues and project risks are shared with the project team and the client including a mitigation plan
- Invoices are produced monthly
- There are important dates (key project milestones, vacations) that need to be shared with the team
- Team member and key project stakeholder information needs to be available for everyone
Ok, so what's next? I know...we will create document libraries for meeting minutes, contracts, status reports, and invoices. We will also create custom lists for issues and risks as well as standard calendar for milestones. We will use web parts to show team member and key stakeholder information. So are we done? Once we build these, they will start collaborating right? Perhaps they will...but aren't we missing something? At this point you have built containers for the information that has been defined. In some cases that's all you need and sure, these containers have versioning and metadata which is already a lot better than storing files in fileshare. However, without enabling some key processes (or understanding what they are), this may be just a glorified repository. And who is to say you have uncovered all of the data/information that needs to be managed on a project? In order to enable a collaboration process, you must first define what it is.
Here are some simple steps for a bottom-up modeling approach we use to identify key activities and high-level processes:
- Identify the tasks: E.g. What do PMs do? Have participants write each task/activity they perform on an individual sticky note. This further breaks down the high level activities identified from your initial conversations and will surface additional requirements and details (approvals, information dependencies etc.). This may also uncover other external systems, areas you may need to dig into a bit more with other stakeholders and the scope of where SharePoint will fit in terms of the overall process (where other people or systems will come into play).
- Group the tasks, label them into process areas and arrange tasks in sequence if it makes sense.
- Identify the people: who are the contributors and consumers of each process area. In other words, who will be adding information or benefiting from the information. In this example, the invoicing process will include the Project Manager, Accounting and Project team members in terms of the end to end invoicing process.
- Identify Inputs and Outputs/End goals. Based on the groups or the processes identified, find out what the pre-requisites or inputs are (E.g. team members need to input and submit their time into the time tracking system). In terms of outputs and the end goal, identify when the process ends. For example, the invoicing process ends when the invoice is sent to the client. The final deliverable and artifact is the invoice that is issued to the client.
- Finally, you can map these process areas and processes into SharePoint functionality and think of creative ways on how you can leverage the platform to provide even more value. For example, you can make use of alerts for key dates (E.g. send a reminder each month for invoices or alert the PM when an invoice is approved etc.).
These are high-level steps of course and make sure you ask lots of questions along the way. You may not get all the information you need from just this workshop but this will at least help you identify areas that need to be fleshed out more/followed up on with stakeholders and subject matter experts.
A wall of stickies from one of our Collaboration workshops
A couple important things to note -
- Make sure you have the right audience identified for your workshops (people who perform similar tasks, have similar or complimentary roles, or in a specific department for example). Identify people that contribute to the scope of work you are gathering requirements for. For example, if you are creating a Project Management site template, invite people who perform or support Project Management tasks. Having a diverse group of stakeholders won't give you very useful results and the activities identified will be too broad.
- This workshop is proven to be effective with a smaller group of people (approximately 8 attendees). You may gather more data with a larger group but you won't get as much dialogue or discussions. The discussions often provide the "meat" or insight into how people work. Schedule 2 hours for this workshop - you will need it :)
The bottom line is, if your process is broken (or non-existent), creating a useful tool requires extraterrestrial powers. The challenge we have as SharePoint Analysts is that SharePoint is seen as the answer to many of your organizational problems. SharePoint can't help them improve "collaboration" when you don't know what it is that people need to collaborate on , why they are doing it and what they need as a result. As the tool, SharePoint helps to facilitate the process and provides more visibility into the process and artifacts.
It's too easy to jump from "what is your business problem" to "here is how SharePoint can help". By doing this we are missing the key processes and things that enable the business to be more efficient, effective and all good things that come when you collaborate.