Application Lifecycle Management for SharePoint

Top Business Risks and Top Project Failures with SharePoint explained.
The Reason for Application Lifecycle Management.

Most people think that SharePoint is something really special and that you need to have a really advanced development lifecycle, operational environment and management, because you can do enormous amount things with it [see image below]. But, when you take a look at SharePoint, it is actually narrower scoped than plain old application development with C# or other development language. I think we still can make a Marslander based on SharePoint, but let’s stay realistic.


With any kind of development language you can build applications which facilitate collaboration, provide content management features, implement business processes, and supply access to information. The benefit of SharePoint, this functionality is already available. So actually a story about Application Lifecycle Management [ALM] for SharePoint is the same story as the general ALM story.

But, due to this narrow scope we can make the ALM story more specific for this kind of application. We can pinpoint to questions like; what are the business risks when using a collaborative platform, what kind of mistakes are common when implementing content management features and how can we minimize these risks and tackle the common failures?

This article takes an ALM view on SharePoint and the specific tasks it fulfills. In what way can ALM solve the common problems when implementing applications and features based on the SharePoint platform? First a short overview of ALM, followed by the common business risks when using SharePoint and how ALM can minimize these risks. Final the more technical view of project failures and how ALM can solve these problems.

Application Lifecycle Management

When talking about Application Lifecycle Management [ALM] terms like accountability, governance and compliance are used. All of them refer back to “working together”, how do we work together during the application lifecycle. ALM is not about tools, it’s about working together. Working together seamless and flexible while staying in control, being measurable and responsible. All the roles in the application lifecycle have a part in this collaboration effort. Tools can help but isn’t’ the core driver.


There are lots of examples of wrong interpreted business requirements, miss communication between development en test, applications which won’t run in production, operations who don’t understand the applications. All of them resulting in more work, more faults, more costs or even only costs and no application because the project was unplugged. Most of these projects faults, these extra costs are a slip in communication.

Having a strategy how people have to collaborate within the lifecycle is one important piece of Application Lifecycle Management. Most organizational parts have already some kind of process / methodology in place. Having an approach how to share information and share ideas from their own role point of view through the other roles is a key success factor for lowering the costs and raises the business value of IT investments.

Tools can help with this goal. Having gear in place which supports and stimulates collaboration is a driver for a successful Application Lifecycle Management. But without a plan, how people should collaborate and communicate, tools are useless.


Lifecycle is a pretty vague term when talking about software development, many processes and pieces in IT use the term lifecycle. For example there is the software development lifecycle, secure development lifecycle, IT-lifecycle, product lifecycle and so on. All of them take a piece of the cake, some overlapping, some even the plate. It’s a matter of definition. In this article the scope of the lifecycle is the born of the idea of using SharePoint till the moment that it’s decided that SharePoint isn’t necessary anymore.

The Top Business Risks with SharePoint

As described in the introduction, SharePoint has a smaller playing field for application development than the most common development environments. Because of this constrained scope we can dive in to more detail risks than general development projects. And find more detailed solutions how we can minimize the risks.

SharePoint is a very rich and extensible application and because of this richness it’s often called platform. A platform from where you can build every kind of application using the wealthy infrastructure of SharePoint. This rich and extensible platform also brings some risks with it, which can be mapped directly on its capabilities.


SharePoint’s richness and its capabilities to extend can cause miss expectations with the business, which can result in dissatisfied users and in an extranet scenario dissatisfied business partners.

The content management [ECM] capability has some other kinds of business risks. Common ECM risks like security, information lost, legal and compliance requirements, governance and the not often mentioned exit strategy.

Another business risk is the usages of the platform. When nobody uses the blogs, wiki’s for information sharing there the business goals of a collaborative environment aren’t reached. On the other side when everybody random uses an creates document libraries, sites, portals, wiki’s and other easy to create parts of SharePoint everything gets too complex to maintain and nobody can find the information he needs.

Risks #1: Expectations

SharePoint does everything and you can change everything, a good selling point but not so good for the expectations. So, how can we manage user expectations? Just by giving them a good sales pitch isn’t the right direction even an end to end realistic demo won’t work. It needs to fit the user scenario.

A business partner in an extranet scenario is a different scenario than an employee in an intranet scenario. Two scenarios with different userstories and requirements, but often the same sales pitch is given to users. As with every project the expectations of the user needs to be managed. There is a strong relationship between expectations and failure.


Users, the business, need to have enough information/ knowledge about the capabilities of SharePoint to define the needs and requirements. Beside this ‘capability’ knowledge, information is needed about the usage of the current available systems. For example it’s completely useless to implement a document management system when the current file server has nothing to do. Or implement a collaborative platform when even mail isn’t used, because all the three employees are in the same room.

For the business to formulate their needs they must have information from development / architecture according to ‘new system’ capabilities, project estimation and reporting. Development need to inspirer the business, need to stimulate innovation in a realistic way.


Next to this knowledge about current usages, current infrastructure capabilities and management is necessary for the business to make a good comparison to define their needs and write down their requirements.

Users think that they can get everything out of the box, everything is possible. For sure this is a pro but need to be managed as important as with a normal project, actually even more.

If your client trusts you, they know you are not trying to get something over on them.... 1 believe that me and the client have to be friends. It’s always give and take.... If you’re not in business with your client, then you’re going to pretty much be up the creek without a paddle.
[Managing User Expectations on Software Projects: Lessons from the Trenches]

Risks #2: Management

While the expectations risks mostly have to do with SharePoint’s rich functionality and its extensibility. Management [as I call it, anybody a better word?] has mostly to do with its content- and document management capabilities. Business risks like Information lost and legal and compliance requirements are common content management risks.

When these risks aren’t addressed, developers and operations will make their own decisions, based on their own knowledge how this should be addressed in the products. Governance which addresses risks and describes processes and guidelines is an import piece of the lifecycle, without it people will make their own assumptions.

But as with any ECM deployment, enterprises need to plan carefully. Uncontrolled SharePoint growth can lead to administrative, compliance, and performance issues. Enterprises must balance staff productivity with operational risk with governance, the right roles, and leverage of traditional enterprise content management (ECM) platforms to support enterprise deployments.
[Forrester governing SharePoint in the Enterprise]


Governance Plan Goals

  1. Establish the service definition and governing IT policies by which the SharePoint service will be run based on the requirements outlined.
  2. Create the people infrastructure to govern and support the SharePoint environments based on the first phase of this collaboration service offering based on SharePoint Server.
  3. Communicate the initial business and initial high-level IT requirements as they relate to the service definition

One important thing that needs to be in place, or at least some people must have ideas around it, is the exit strategy. For any kind of reason there can be a decision to stop using SharePoint. For example a takeover by a company which uses something else and you need to migrate. If you decide to move off the platform, how much of the custom integration work will be lost?

Risks #3: Usage

How SharePoint is used and adopted by users within an organization, if it’s implemented as an internet, internet our extranet solution has many facets. The usage can be from no adoption, no one uses it, to heavy usages and everything in between. The trickiest risk with an enterprise wide implementation is that adoption levels vary by users. Some use it heavily some don’t, which will result in big business problems. This counts especially for the collaborative features of SharePoint.

Just implementing SharePoint isn’t an option there needs to be more in place to get the usages at the right adoption level and minimize the usages risks. Sogeti has written a book together with Microsoft about Collaboration in the Cloud where the aspects of adoption of collaborative tooling are and treated.

tag3 - Copy

[Tag Cloud from the Collaboration in the Cloud Book, available early April]

Creating new modes of collaboration supported by technology can only be done by addressing the human aspect. More specifically, we need to address some of the worries and obstacles people encounter when collaborating using technology.

The three most important concerns are:

· Trust. Trust is a condition for social interaction. People will only work with people, companies, tools and information they know they can trust. Before we can expect collaboration to take off online, there must be a way for people to get this “trust.” And a topic closely associated with trust when it refers to people is Identity.

· Collaborative culture. If one individual is the greatest collaborator in the world, he or she is probably not getting anywhere. Only when all people involved are part of the same collaborative culture will new levels of creativity and productivity be reached. A collaborative culture consists of many things, including:

    • Collaborative leadership;
    • Shared goals;
    • Shared model of the truth; and
    • Rules or norms.

· Reward. Changing the way people work takes effort, so it must be clear for the parties involved what they will gain, at a personal level, from collaborating in a new way. Surprisingly, a “reward” for successful collaboration is most often of a non-financial nature.

“The ways that people work together shift over time, which can affect your culture of collaboration. More important, the introduction of collaboration technologies can also change the culture of collaboration. If handled properly, the tools and the culture will coevolve.” 
Dennis Kennedy

The Top SharePoint Project Failures

SharePoint projects, implementations and extensibility, have some special characteristics which need to be taken care of. The same as mentioned in the ‘business risks paragraph’ SharePoint has a more constrained scope than general development projects so we can dive in to more details of the project failures.

Common project problems arise when these areas aren’t thought of:

  • · Support responsibilities
  • · Product complexity
  • · Hardware
  • · Performance
  • · ALM project complexity
  • · Deployments
  • · Future ready
  • · Audience Awareness

Even more as with general ALM projects the infrastructure and the operational rolls need to be involved in the early stages of the project. SharePoint maintaining can get very complex with all the different kind of server products involved. Infrastructure and operations needs to be prepared, ready with the hardware and ready with the knowledge they need to maintain the environments. Processes and responsibilities need to be in place before the start of the implantation. Otherwise the developers are sucked in the administrators roll, because they are the only one with the right knowledge.


One of the most challenging project tasks, and most error prone, is the deployment of new functionality. The main cause of this challenging task is the rich authoring capabilities of SharePoint. At many levels people can change, link, replace and add functionality.


Users can change sites just by using the browser. Power users can change and create new functionality by using Office SharePoint Designer. Developers can add functionality by using Visual Studio and off course administrators can do their thing thru the browser or the management console of the server products used.

This wide variety of possibilities to change functionality is challenging to manage and makes it necessary that all the rolls in the application lifecycle communicate on how, when and what is editable at what level and with which tool. The main question is; if you decide to change, edit or move functionality, how much of the custom integration work will be lost?

Different deployment scenario’s must be in place and communicated with the business, operations and development. The Patterns and Practices group from Microsoft has done a great job in describing these scenarios in the SharePoint Guidance. In the first release of the guidance packaged applications which are created with Visual Studio are described in depth.


When you plan your deployment and upgrading strategy, consider each stage of this cycle. For example, you need to understand how the application will be used, how you will develop the application, how you will package it for deployment, and how you will manage data that is maintained in different environments. The following are other issues to consider:

  • Will you ever need to upgrade this application?
  • Will you only need to add functionality without changing the existing functionality?
  • Will you package this application for broad distribution over multiple application versions, for example as an independent software vendor (ISV), or across the enterprise?
  • Do you control all sites where the application is deployed?
  • Do you need to preserve customizations from version to version?
  • What is the governance model? For example, consider the following:
    • Do you have sensitive data that developers should not access?
    • Can you make changes in production as part of the development process?

[from: SharePoint guidance on MSDN]

The second guidance [in development] will describe the more complex scenario’s of SPD based application construction and browser authoring and publishing. [SharePoint Version 2 Guidance -Enterprise quality, content driven SharePoint applications]


Comments (1) -

wow nice information.. thankss

Add comment

Şarkı Sozleri