The very first thing you must document is the stakeholders. The term stakeholder has come to mean something very different than its original meaning. Merriam-Webster defines a stakeholder as "1: a person entrusted with the stakes of bettors; 2: one that has a stake in an enterprise." Until recently, the only definition was the first. In the modern era of engineering, the term stakeholder has come to mean those who have an interest in a project—essentially those who will gain or lose from the project. If you are following a framework such as ITIL in your environment, the term stakeholder may have already been defined for you. The following are stakeholders you will commonly need to deal with as you implement SharePoint Server 2007:
Customers. Often, the person or group responsible for paying the bill becomes the most important stakeholder. We refer to this person or group as the customer. Unfortunately, customers are not always the users, and they do not always agree with those who will actually use the product. While the customers’ opinions are certainly important, try to help them understand that if the needs of the users are not met, the project success rate is greatly decreased. If the customers are unwilling to listen to the users, you are in for a long, uphill battle.
Users. SharePoint Server 2007 is an end-user product. It was developed for end-users to empower them to quickly and efficiently collaborate. Unfortunately, users are often not asked their opinion about SharePoint Server 2007 until after it is installed. End-users are arguably the most important stakeholders in your design. As was discussed previously, people are resistant to change unless they are included in the change. Including your end-users early in your SharePoint Server 2007 project increases your chances for success. You could have a free lunch and learn, hang posters about SharePoint Server 2007 and why it is good for them, provide end-user training, or even show them their favorite Web sites that were implemented using SharePoint Server 2007.
Departments. Another important stakeholder is the departments or divisions themselves. Examples are Sales, Engineering, Manufacturing, Marketing, Information Technology, Human Resources, and Security. Many times departmental input can make or break a design. Try to find the people who make these departments run smoothly, and ask what the software can do for them. If you have a prototype system currently running, department managers can often provide valuable input into the future design and use of the system. Be sure to show examples of SharePoint Server 2007 functionality and ask what their current pain points are with their current system.
Executives. Executive input is almost a necessity when implementing a product like SharePoint Server 2007 because it is likely to have a wide-reaching impact in your organization. We say almost, because if given enough time and money, you can be successful without their support. In a perfect world, your SharePoint Server 2007 implementation is being driven by the executives. You should explain and demonstrate that, before it is installed, SharePoint Server 2007 needs to be properly planned and designed. This will be much more difficult if you have simply been ordered to install SharePoint Server 2007. If you were told to "install SharePoint Server 2007" with no executive support, then you must document how a hastily implemented SharePoint Server 2007 project will negatively impact your workplace and present this information to your executives.
Supervisors. One stakeholder not to forget is usually the person you work for. If you an administrator, it may be the CIO or Information Technology Manager. If you are the CIO or Information Technology Manager, it may be the CEO or another executive. Whoever it might be, it is very important for this person to be involved in the process as much as possible because SharePoint Server 2007 almost always changes the culture in an organization. At a minimum, be sure to invite the person you work for to every design review.
After you have defined stakeholders and gained some support and momentum, you must train the project staff. You cannot skip training and go directly from defining stakeholders to gathering requirements because you will not know the questions to ask.