Before you begin adding customization tools to SharePoint to create a solution for your business, you must understand your company’s business problem. In this article, I cover a few important areas you need to address before you look at technology.
One of the most powerful features of SharePoint is the ability to combine out-of-the-box features to build a solution. With a little training, you can create sites, workspaces, libraries and even charts and reports. Combining these, you can develop solutions, such as corporate intranets, FAQ Sites, Knowledge Bases and even Project Management solutions. All of these solutions have the potential to provide a tremendous amount of value to the organization.
There is much advice and direction in the community on how to build these solutions. In fact, there probably isn’t a solution that you are looking to build in SharePoint that hasn’t been built before. But even though I have listed several common solutions, there is still one factor that makes your implementation stand apart from others -- you! Your organization is unique, and, just like snowflakes, there aren’t any two organizations that operate the same. This means that, while all organizations may need a common set of solutions, they still need the ability to customize those solutions so that they are a fit for their environment.
This is where the power of SharePoint becomes evident. Because of the available customization tools, you can build what your organization needs. This means you can implement custom solutions to address your biggest business problems. The key to the success of these solutions is the relationship between the solution and the business problem. To satisfy the business requirements, you need to be willing to throw the technology out the window and focus on understanding the problem.
Understanding the Problem
The first step to this approach is to dedicate enough time and resources to ensure that the business problem is understood. This means you need to spend time looking at the big picture, the immediate needs, as well as the long-term needs. There are many ways that a problem can be presented to you. For example, the problem can be addressed from above when a manager informs you that you will build a solution to solve X, or it can come from below where your users are begging for a different solution to address Y, or it can simply be a problem that you observe.No matter how the problem finds you, you need to have a good plan in place for validating the given scenario. This must be done before you go any further because this will affect the rest of the design process. By identifying the problem, you will also be identifying the scope of impact and the users that you need to work with. Listed below are some common questions that you should be looking at as you are working to identify and understand the problem:
- Who is requesting this solution?
- Who in the organization would be using this solution?
- What are the specific goals associated with this solution?
- What potential risks can be identified if nothing is done to solve this problem?
- Is there an existing solution in place? If yes, how do users feel about this solution?
- How does this solution relate back to the direction and goals of the organization?
- Is this solution request associated with clearly defined business processes or would that need to be defined as part of this solution creation?
Answering each of these questions can help you identify the scope of the solution request, and by focusing on these questions first you will be able to get an understanding of what the problem is before you look at the technology.
Understanding the Organization
Once you have an understanding of the problem, you need to next look at the organization. This means that you need to grasp the organization culture and the users within the organization. You can build the best technical solution for any problem, but if it isn’t a good culture fit for the organization, then you will likely have a few problems when it comes to user adoption and measuring success. After all, if no one is using the world’s best technical system, then it isn’t the best solution for the problem.
Take a small manufacturing plant as an example. If the current process they have in place involves printing reports and manually delivering them to the required recipients, and the new solution includes a process for filling out a form and pressing a single button, they may become overwhelmed because the new process is so different. Does this mean that you can’t automate solutions? No, but it does mean that you should automate things and be sure that you know the audience enough to make the best experience for them.
Learning Opportunities
In my example, this may mean taking extra time on the user interface to ensure that even though they are starting a process, they have an understanding of what happens when they submit. On the flip side, if you take an organization that is automated, they would expect that certain things happen when you provide a submit button. The key is that you are building solutions that match your organization. And because your organization will change over time, so should your approach to building solutions. By making this part of the process for defining requirements, you will be able to adapt solutions based on the organization’s current culture and user base.
Understanding the Process
The final area discussed in this article is the area of business processes. This is one of the primary areas that can make or break the success of your solution. One of the best things you can do to guarantee a successful project is to ensure that you take enough time to map out the business processes that are required in completion of the solution. You will want to make sure that all of the project stakeholders have thought the process through and are able to define what should be happening at each step. If you don’t spend enough time on this phase of the requirements gathering, then you will likely be in a situation that requires you to change requirements in the middle of the implementation. This is risky because you may find that the changes have a significant impact on the timeline and/or the functionality.
I know this sounds great in theory, but the reality is that most organizations struggle in this area, and try as you may, this step of the solution’s requirements gathering may be impossible to complete. When you find that is the case, then be encouraged to know where you are at and identify your potential risks. Continue to build your solution, but understand the gaps you have and design to those gaps. Listed below are two common approaches that can be taken in this scenario:
- Think Big, Start Small and Keep Growing:In this approach you look at the problem from a high level, but you build for a small subset of features. Over time, as the process is defined, you keep adding features.
- Provide Partial Functionality: In this approach, you may use a simple workflow that provides partial automation. An example of this might be that users can route a document for approval, but they have to enter the names of the approvers. They will continue to use this workflow until we can define a process for identifying who the document should route to for approval.
Mapping the Problem to the Solution
We have covered a few areas that are important to address before you look at the technology. Now, because we have identified and outlined the specific business problem, the current environment and the detailed processes, we are able to begin to look at the technology. Knowing what we need to accomplish allows us to better select the proper customization tools we will use.
The more we improve our ability to understand the business, the better the solutions we will be able to build. SharePoint is a great tool with an abundance of features that can be customized to meet specific needs. As you continue to learn the features of SharePoint and the functionality it provides, you need to remember to be thinking about the business and ensuring that you are putting them first when it comes to the solutions you are building.
Editor's Notes: You may also be interested in reading: