The requirements that have been identified fit well with the SharePoint platform. So well, in fact, that a number of decisions need to be made regarding which direction to go technically. This section will walk through some of the decisions made for this particular scenario.
The RFP process is a good representation of how business processes should be addressed in SharePoint. Taking a business process and trying to jam it into the SharePoint platform is the wrong approach and often very frustrating. It’s analogous to trying to fit a square peg in a round hole. What is effective, however, is to analyze a process and identify which steps fit into the SharePoint model and will deliver the most value. As initial automation steps are found to be successful, additional and potentially more challenging automation can be added at a later time. You will be addressing the first iteration of an RFP process in this chapter.
One of the benefits of using SharePoint is that it provides so many ways to solve a particular problem. The challenge is picking the best approach possible for the specific instance and to start in a way that allows the solution to evolve over time.
Where should the RFP content be stored? Should the libraries be part of an existing site alongside other lists and libraries, or should they be isolated in a site collection or a subsite? Each option has its pros and cons.
From a security perspective, a separate web or site for RFP content allows the separation of security settings from other content, which is common for estimates, bids, and proposals. The security for the separate web can stop inheriting the permissions of the parent and be managed independently.
Technically, the lists can be part of an existing web with other content, although creating the lists in their own site collection or web offers advantages in both navigation and security. From the navigation perspective, a new web allows the left navigation area to be used exclusively for RFP process functionality, so you avoid cluttering up an element that is also used for what may be many lists, libraries, and subsites.
Whether the solution is built as a stand-alone site collection or as a subsite is determined by the information architecture of the SharePoint environment. Either option allows for the necessary security isolation.
For this example, instead of allowing all users access to the content, you’ll create a subsite of another site to accommodate specific security needs.
For this solution, both the Blank Site and Team Site templates work for the solution, although some features of blank sites that you might want to use for future enhancements are turned off. You will be using the Team Site template that is available in all SharePoint 2010 and Office 365 SharePoint Online versions.
The team site comes with the wiki functionality already enabled, but it also comes with a number of lists and libraries that aren’t specifically called out in the example.
List template selection for the solution is fairly straightforward. Most of the content will be managed in document libraries with additional configuration of new fields and views. Additional lists may be used for reference information (like companies) as needed.
In addition to the list template question is the question whether to use one or more libraries on the site to manage the content. Should all documents be stored in a single library using content types to allow different columns for each document type, or should separate libraries be used?
Option 1: Single library
All documents related to RFPs: incoming documents and deliverable documents
Separate content types to allow for columns for specific document types.
Users need to select the document/content type when uploading documents
All documents related to an RFP can be grouped together in a folder
Consistent security across all documents unless folder or document-level security are also implemented.
Option 2: Separate libraries
One library for RFP documents
One library for response and support documents
Supports unique security on each library
Documents from one library need to be associated somehow with related documents in the other library.
Users don’t have to choose the content type when uploading docs.
At the cost of a little more effort for users to have to select the document type when uploading and security being the same for all content by default, Option 1 will be used in order to simplify relationship management between documents. In addition, folders will be used to keep related documents together.
By using a subsite for the solution, you don’t need to worry about inheriting users or groups, but you will set up at least one additional security group in addition to the default Visitors, Members, and Owners groups.
The solution you build will involve a volume of documents that will grow larger over time, but the volume will not likely be so large as to cause concerns from a technical boundary (number of documents in a library), a database sizing, or a disaster recovery management perspective. If necessary, the site could be created as a site collection to isolate it in its own database, or a policy could be put in place to archive older documents to keep the size at a lower level (ongoing processes to archive older documents as newer documents continue to be added). These are both scenarios outside the scope of this chapter.
The solution will also be using workflows that will create both task and history lists, but neither should be so large as to cause concern. Lists and libraries can technically hold up to 30 million items per list. If each RFP workflow is creating two tasks and less than 10 history items, it would take a lot of RFP processes to even begin to challenge the technical limitations of the platform. Therefore, there isn’t a threshold or scalability concern for this solution.
