SharePoint-InfoPath.com

Using SharePoint's rich set of capabilities and easy to use site creation and management tools, it makes it possible to throw together a few sites with lists, libraries and workflow when developing business solutions. Although powerful, and if controlled appropriately can be efficient and useful, care should be taken as many shortcuts will result in non adoption of the solution once implemented.



Using the security model provided by SharePoint, ownership can be handed to users of the SharePoint environment, to allow sites and components to be added and configured by other users. As end users will not have the same understanding of the capabilities of SharePoint to a developer or administrator, you will sometimes see site and list templates being used inappropriately, when there are other resources available that would be much more suitable. The same also applies to the planning and development phase of a solution for developers, as it is sometimes an attractive solution to develop a system using core site and list templates in a matter of minutes without putting an appropriate amount of thought into the process.



A solution may seem to work as well as to be practical and intuitive, but this is often only the opinion of the developer or owner of the system or concept. Until tested and validated by sample group of test users who closely represent the entire user-base, the number of assumptions made should be kept to a minimum to prevent having to re-develop components of the solution unnecessarily. In many cases, the core features provided by SharePoint will provide the means for a suitable solution with minimal and only minor customisations required. Once the components (content types, lists, libraries, etc.) have been put in place, it is often only a case of designing and developing an interface that pulls the components together seamlessly to make or break the solution. SharePoint core list templates can be used and reused in an indefinite number of ways, but it is how the users interact with the list that can be a primary difference between two different instances of the same list template.



The key is to be able to interpret requirements into a viable solution without over complicating the design. Time will is generally best spent working with and customising the lists, libraries and worklfow provided by SharePoint rather than building custom extensions and web parts, but there are cases where an extension should be written for a solution. Having a good understanding of the capabilities of SharePoint is essential when designing a solution.



Project Task Management Example

For example, a site may be configured to allow a team of people to manage a project. The project has been broken down into a small number of primary phases, each with a set of tasks involved. Tasks lists provide a set of fields that provide the bases for creating and assigning a task. It would be possible to build a solution that is highly customised to be tailored to the needs of end users, but a solution could also be designed and developed using core features of SharePoint such as task lists and associated workflows, with minimal customisation required to achieve a similar result.



Other requirements as a suitable technical solution that can be developed to a satisfactory level with the least amount of time and effort required. As SharePoint provides a range of core capabilities, these should be utilised as much as possible to get more value from the invested development resources.e possible solution could be to use two task lists to manage the process:



1. The first would store information about each primary phase in the project, start due dates for each phase and the person responsible for overseeing progress of the tasks involved.



2. The second list could also be created from a standard task list, with a lookup column pointing back to the primary task list to associate the sub tasks with a primary phase in the project.



Even though the two lists are both task lists, users would interact with each in different ways. The primary list would be used closer to the beginning of the project when planning the schedule, but would be referred to throughout the project. It would need to contain a record for each primary phase in order to associate sub tasks to each phase during the project.



A higher level user such as a project or team manager would need access to maintain both the primary task list and the sub-task list, but project team members would probably only need access to manage items in the sub task list. The primary list could be named "Project Configuration" or similar, where the sub-task list would be something more along the lines of "Project Tasks", "Action Items", etc. It would be possible to achieve a similar result using content types and a single task list, where allowances for major tasks / project phases are included as well as sub tasks associated with a primary task in the list. Having two separate lists gives greater control over the matrix of project tasks and information, including the ability to configure separate permissions on the primary task list if required to allow only a manager to maintain project data and the primary phases.



Workflow could also be used to manage each task to be completed in a project, with preset reminder dates based on the due date of a task in the primary or sub task list. The amount of time that a workflow waits to remind someone that a task is overdue may need to change in future. Instead of needing a developer to update the workflow to wait for the new length of time, this information can be stored in a list in SharePoint that the workflow refers to to determine how long to wait. The list containing the control data can then be maintained by users, eliminating the need for a developer to update the worklfow.



Control Lists

Using control lists can be a great method of handing control of a solution over to users, as well as allowing greater overall functionality of a solution. Email notifications sent by workflows will often require major or minor adjustments to the message or information contained in the message. Storing messages or instructions to users in a separate control list also allows users to easily make changes to the message without having to modify the workflow. The workflow would then use the value in the control list item when building a string workflow variable to be used as an email body or elsewhere. As mentioned above, when a workflow is to wait for a specific amount of time, the value can be stored in a control list item and referred to by the workflow instead of incorporating the value into the workflow explicitly. Other uses may be date or other numeric thresholds for when a workflow is to respond differently when the the value in a list item field is above or below a certain value.



I like to configure control lists as a custom list, where the title is used to describe the type of control, and also used by the workflow to find the correct list item and corresponding control value. Other fields include a text field for text, string or character data, a number field to store date and other numeric thresholds and a multiple line text field to include some notes about how to use the control. Permissions can be set on the list to ensure that items can be removed, as well as to restrict access to be able to modify control data to specific users. Having only a small number of users with access to maintain control data helps prevent human error, and reduces the number of users that require training on how to maintain the system. Enabling version control on the list will at least give you information about who makes changes in the control list if required.



Knowing what components are required by a system, as well as to know how they are to be used in essential during the planning stage to ensure that the solution decided on is appropriate. Some of the thing that should be considered are the amount of time and skill required to develop balanced with the type and ease of usability. Throwing together a few lists on a SharePoint site coupled with a page with web parts displaying contents of the list can be an efficient way to develop a solution, but it the interface is not easy to understand and use, then the system will not be adopted properly or at all by users. Taking shortcuts during the design or development stage will almost always result in poor user acceptance levels.



SharePoint Development Resources