SharePoint Project Management as a Service

In the wake of increasingly complex IT architectures that are prevalent in companies, the cost to control medium and large IT projects increases disproportionately as integration, interfaces and requirements become more time consuming and non-transparent. To counter this trend requires standardized development and especially a project management methodology with defined interfaces, input and output artifacts and a best practice model. One solution is the SharePoint Project Management as a Service (SPaaS) approach, which combines the flexibility of a catalog-based approach to the security of a fixed price offer.

Changing Conditions | Adapted Approaches

The last few years have brought about significant changes in the IT industry in the areas of governance and implementation, but also in terms of pricing. Due to the increase in IT-related costs, companies started to develop strategies to reduce these – especially in system integration and custom application development. These approaches, include outsourcing, preferred supplier implemented strategies and standardized project process models. But it is precisely in the area of complex SharePoint projects these approaches hit their limits, since they can not successfully address the specifics of SharePoint development with regard to expectations, complexity and lack of market experts. In addition, rising costs in project management on both sides – the customer and the service provider by phenomena such as scope creep, failed deployments and complex requirements engineering processes. The resulting price pressure can lead to a deterioration of deliverables and also partly to project failure.

The above mentioned text of the standardized project approach, for example PMI or Prince2 only has a limited affect for Custom Application Development projects because of the specialty of SharePoint development. From our experience we have seen that it clearly increases the implementation costs of SharePoint Projects. To counter this issue the SharePoint project management as a service (SPaaS) offering was developed. It is based on a catalog of SharePoint-specific artifacts, which can be ordered at a fixed price. Depending on the complexity of the project, which is directed to development effort, the number of involved departments / service providers and the system environment. The artifacts in the catalog are classified as simple, medium and complex and thus have different price-based profiling overheads. At the same time, the complexity also determines which artifacts from the framework are “mandatory”. For example test cases in a standard SharePoint project are classified as “simple“, whereas large projects including a detailed test plan and release plan, management of regression and user acceptance testing would be classified with higher complexity.  All artifacts can be ordered at a fixed price, allowing your customer to create detailed cost planning upfront. This fixed price applies for the control of developer resources, pure project management on behalf of the customer, as well as the control of other service providers in connection with the transfer of management tasks. An advantage of the SPaaS approach is the way it can integrate into existing process models, the requirements of the existing approach and the SharePoint project future state.

SPaaS in Detail

The SPaaS framework will be explained below with reference to two different SharePoint artifacts from the framework – Release Notes and SharePoint Code Analysis. SharePoint-specific artifacts can be found in many different areas. There are different artifacts to cover the many characteristics of simple to complex SharePoint projects as well as the different technical focuses. These range from infrastructure planning and security, information architecture, and application development guidelines to an operations manual, deployment guide and solutions. The corresponding solution approach must help to address all these issues according to best practices, artifacts and lessons learned from previous project experiences.

The SPaaS framework therefore comprises a variety of SharePoint-specific project management and service artifacts, checklists, special processes and acceptance criteria which are interconnected by Quality Gates for successful implementations.

In any project, all artifacts are needed, but felxibility is a key advantage of the SPaaS framework – the artifacts can be built into customer process models required for the project.

Figure 1 – Integration of SPaaS in a client framework

Figure 1 shows a process diagram, how to integrate the artifacts from the SPaaS framework into your customers existing procedural model. The artifacts can be included in the catalog at different times in the project. The number of artifacts that can be included in the framework are also flexible.

Release Notes – Comprehensible Deployments

Release notes are brief documents that are passed to your customer along with installation packages. Release notes can be used for testing, as documentation for final solution packages or as documented evidence for solution enhancements. Release Notes provide the customer an overview of the solution and support for typical operations such as installation or removal.

The header of the release notes is the “Package Information”. This provides general information on the delivered object, such as the name of the package, version, if the package is still under development or if it has already been tested and is the final solution. In addition, it specifies which area has been developed in the package and how it is distributed.

This information is for a recipient, such as a platform administrator and is an important artifact for them to decide how to proceed. Typically the decision on how to proceed is decided based on the information contained in the “Release Types” section that indicates which environment the package is installed on. This information can prevent an unfinished package being released to a production environment. Similarly, the “Target Environment” information also aids with this. This information is also useful in situations where the customer has more than one environment in order to have an overview of the environments and ultimately eensure the operability of the platform. It is especially useful in hybrid architectures (cloud and on-premises farms in mixed mode).

Figure 2 – Example Header Release Notes

The second section of the Release Notes describes the contents of the package in more detail. All SharePoint solutions, documents and PowerShell scripts are referenced to facilitate the receiver who needs to deploy and manage the solution. For example:

• Solution Package:       customer.workflow.customsolution.wsp
• Deployment Script:     SharePoint Deployment Guide for CustomSolution.docx
• Installation Script:       Install-CustomSolution.ps1
• Update Script:              Update-CustomSolution.ps1
• Remove Script:            Remove-CustomSolution.ps1

The references on individual scripts provide clarity regarding the handling of the package. Especially for large solutions that consist of several parts, the administrator typically likes to have a clear understanding of how to handle the packages supplied. If this information isnt‘ available it’s possible that features are recorded manually or installed in the wrong order and activated. This leads to errors and can unnecessarily increase the cost of the deployment.

The third section of the Change log represents the history by means of a change log. It enables the recipient to understand what changes are incorporated in the current version such as bug fixes. The traceability provided also helps control testing activities. The Change log contains the number, type and description of the change.

Example Changelog:

• #9960 –          Type: Bug             Search should be accessible in Quick Launch via…
• #9963 –          Type: Bug             All Site Templates and Features should be hidden
• #9964-           Type: Bug             Vertical Scrollbar within Contacts form
• #9965-           Type: Bug             White space between Ribbon and formula appears
• #9982-           Type: Bug             Search result are not in customer’s Branding Style
• #10010          Type: Bug             JavaScripts are referenced incorrectly

Also in the change log, the recipient has an overview of the changes to the package after testing has been carried out. Since testing and development cycles can be run independently and asynchronously, identified defects can be found and corrected simultaneously. In order to not lose sight here, all bugs and their status are defined in the Change log. Inevitably this reduces effort, since your customer and project team are all viewing the latest status.

In the last section of the Release Notes additional comments and information is available for document control. Decisions can be traced back and release management requirements are also taken into account here.

Example Comments:

“This Release includes the implementation of the new branding strategy. By default the CustomSolution solution doesn’t include any custom branding. It also does not include any custom masterpage. The custom search is now integrated in the left navigation as well.”

Release Information:

• Approved by:                               SharePoint Architect 1        (SP-Arch@company.com)
• Release by:                                   SharePoint Developer 1 (SP-Dev@company.com)
• Release date:                                01.01.2013

Release information is especially important if the development team is larger and/or there are errors or queries during the deployment. In this case, it is important for the administrator to know exactly which deverlopers or architects to contact for a quick resolution.

SharePoint Code Analysis – Maintability and Quality

Code analysis ise carried out according to the SPaaS framework. This is an important component to ensure the solution delivered is of high quality and performance, maintainable, and stable. Therefore, code analysis at each code check-in takes place in the TFS (Team Foundation Server). Here, the various stages of development, test, integration, and pre-production can be used to enforce various strict rules for check-in.

The rules by which the code is analyzed comes from two different sources. For the writers, these sources are best practices that have emerged from our project experience as well as from Microsoft. Furthermore, there are custom development guides with which the developed code should conform. Depending on the size and scope of the project, the production of a development guide is an artifact embedded in the SPaaS framework.

The extensive set of rules that have been developed from the two aforementioned sources cover the following areas:

• Robustness: exception handling, logging mechanisms, Defensive Programming
• Maintainability and adaptability: duplicate code, length of methods, layer architecture
• Performance: communication between SharePoint and applications, boxing / unboxing, reflection, drop (dispose) of objects

Additionally, code metrics, like in Visual Studio, are used at TFS code check-in. Together with differing limits for each category, a quick overview of the solution can be obtained.

Namespace:                                         Provider.Features.Farm
Maintainability Index:                              68
Cyclomatic Complexity:                            26
Class Coupling:                                        33
Lines of Code:                                          67
Status:                                                   Green

Namespace:                                         Provider.Helpers
Maintainability Index:                              83
Cyclomatic Complexity:                            41
Class Coupling:                                       15
Lines of Code:                                         63
Status:                                                   Green

The code analysis process in the SPaaS framework provides obvious advantages from all sides. Your client receives a report of the code quality at designated times, they have a standardised tool that is ready for use, reducing effort time required during and after the solution has been been deployed, and your developers also receive a report regarding the quality of the code each time they check-in to TFS.

Conclusion

The advantage to perform a SharePoint project leveraging the SPaaS framework is particularly evident in larger projects. Safeguarding higher quality for all artifacts needed and the comparable output-quality in the course of the development are the two most important. Through the consistent use of templates, the SPaaS framework has proven to be highly effective, allowing us to standardize project results to a large extent. In particular, comparing individual artifacts across different projects running in parallel and even beyond the current project.

The processes of the SPaaS framework connect the artifacts with each other, while providing comprehensible and transparent decisions during the project lifecycle. The customized documents, checklists and guides from the SPaaS framework should be combined with documents from your customers existing process models and used to carried out a quality gate assessment. The quality assessment level is determined based on various criteria checklist, completeness of the documents and the overall progress of the project.

The adaptability and flexibility that the SPaaS framework provides for business processes and various process models allows for the SPaaS framework to be used for a wide range of SharePoint projects.

For customers, the transparent and predictable cost structure for the management of SharePoint projects is one of the main aspects that makes the use of this approach highly valuable, especially for more complex projects.

Download EBook: Share Point 2010 For Project Managemet

About the Authors: Sebastian Gerlingis & Lana Khoury

Sebastian Gerling

Sebastian Gerling is Division Manager at CGI Germany responsible for CGI’s Microsoft Business Productivity Consulting team. He is mainly working as a project manager for large scale SharePoint and CRM projects.

In addition, he is founder of the Nuremberg SharePoint User Group, leader of the Munich SharePoint User and Cloud Group and is a regular speaker and author for SharePoint publications and at events across Europe.

Lana Khoury

Lana Khoury is the Digital Enterprise SME in the Chief Innovation team for CGI’s largest global accountresponsible for developing and delivering innovation in the domain of Digital Enterprise, specifically Customer Experience, SharePoint and Salesforce.com.

Lana has worked with Sebastian on other SharePoint articles published on the European SharePoint Community, in the DIWUG e-Magazine (Dutch Information Worker User Group) and presented at the Belgian Information Worker User Group and SP24 – the world’s largest online SharePoint conference.

To see what Lana is sharing in her network follow her here

Check out the 2014 European SharePoint Conference video:

European SharePoint Conference 2015 takes places in Stockholm Sweeden from 9-12 November 2015.