There are a number of challenges that come with obtaining and implementing user requirements which have an equal impact upon the end users, the IT department and the SharePoint technology itself. These are outlined in the following sections.
A department has requested that SharePoint assists with a business process and a requirements meeting is set up.
The department and users need to be aware that there is a process/methodology in achieving the end result. This is not a one shot deal, and they are involved in the success of the project.
Prior to the meeting, the department should have the following answers prepared.
- What is the department trying to achieve?
- What are the pain points of the current environment?
- Is anything going to be approved (as an?) Excel DOC, submitted form PDF?
- How many steps are involved in the process?
- Who is involved in this process? (Submitters, approvers, or content viewers)
- If there is a business process, how should it flow?
- What are the critical success factors of using SharePoint?
- How does SharePoint help these critical success factors? (The more factors ticked off the better. If none are ticked then it goes to the back of the queue).
- How does the process start and end, and are there milestones involved?
- When the process goes live, who will be the owner of the process?
- Does SharePoint bring new business functionality to the process?
- What are the strategic objectives of this initiative to the business?
If the preceding points cannot be answered either prior to the meeting or during it, the business process has not been thought out, and the SharePoint solution is more likely to fail.
Often, the users will not be aware of SharePoint's capabilities, so there will be some educational aspects of such an engagement:
- SharePoint is a template technology. Must users work with this?
- The implemented approach will be out of the box with no coding—are there limitations?
- How can SharePoint be better than your existing process?
- What is required from you, the user?
- How much training is required by you?
At the beginning of an initiative, a simple process can become quite complicated, so it is important that complex requirements are identified at the beginning of the requirement gathering process.
Often, an IT department will implement the free version of SharePoint (Foundation) on a spare server, resulting in rumors within the company about a SharePoint deployment. This may have the effect that a tidal wave of requests for SharePoint applications from business units will come in, and this is all deployed on a test deployment.
Fast forward three months: the server has run out of disk space, the IT department is reading the manual to understand how to restore a deleted file, and users are complaining that SharePoint is not living up the hype. Unfortunately, it is all too often that the IT department will then adopt a have-a-go approach to the SharePoint technology.
A SharePoint installation and deployment needs to be carefully thought through with a one to three year plan of business usage and infrastructure considerations. This should be reviewed every year to assess the business requirements.
SharePoint is a versatile platform, but all SharePoint business processes do not need to be deployed on the same server or within the site collection. Often, companies will install SharePoint on a server or server farm, and insist in driving all their initiatives off it, with the attitude that, We have SharePoint deployed, let's do it on the existing SharePoint infrastructure.
A good example of the Just Do It attitude is when a SharePoint application that was originally designed for employees is now being accessed by non-employees, and access levels are being set up as if they were internal users.
The IT department must engage with the business and users. This statement is not profound, but with SharePoint deployments, because users have the ability to customize and personalize so much functionality, the user experience, and ultimately the success of the deployment, is not a result of formal training sessions, but rather from users experimenting and making slight adjustments to features such as alert notification, meta tags, and their My Site so that it is personal to them.
We might estimate that 40 percent of the user experience is the personalization of notifications, pages, and the general look and feel, rather than what someone else did in building out the functionality. This is very different to other applications and is the reason why low touch, low value SharePoint deployments are as they are because the users are not aware of the functionalities that are all out of the box.
Note
Recruiting evangelists throughout the organization is the only way to make a big project of any kind work. Usually, any new technology or process that is visibly promoted by only the IT department is difficult to be universally accepted across an organization.
People need to be nurtured, educated, and inspired to use the technology so they see the value.
Another challenge for the IT department is to understand the actual request from the business. Often, there is a request for a team site for a business function, when in reality a document library was all that was required.
One of the really nice things about the SharePoint technology is that the specifications do not all necessarily have to be required at the beginning of an initiative. Functionality can be added after the release, and even by the users themselves. This is different from traditional IT projects where requirement gathering is documented, but a true understanding by users of the process is incomplete.
With SharePoint deployments there is the ability to engage users with proof of concepts very early on in the process. This allows the users to become more confident with their own SharePoint skill-set and take ownership of projects.
By users taking ownership and personalizing content and design, the endless list of small requirements can be done by the users themselves.
We recommend performing follow-up coaching sessions, and having the more vocal people speak out about the small alterations they have made to a deployment to educate the other team members.