Almost every successful development project goes through some sort of formal lifecycle; a process that involves a series of steps leading up to the completion of the project and its transition to a production environment. There are endless variations to this process, also known as methodologies or development frameworks, some of the more commonly known flavors include; Microsoft Solutions Framework (MSF), and the Rational Unified Process (RUP).

While many of these methodologies vary significantly in execution, most of them share many of the same principles;  define, design, develop, test, deploy, stabilize. Every one of these principles always appear in one form or another. Depending on how long you’ve been in this industry, you are probably familiar with them and their importance. If you are not, or simply don’t believe that they are all that critical, your probably just starting your career or perhaps should consider taking on another one.

So how does this process relate to SharePoint? In the same way it relates to any other Application Development project. Yet somehow, with SharePoint solutions, many of the principles are often disregarded. I know that’s a general statement, but based on what I see every day in the SharePoint development forums, comments on blogs, and helping out my clients; I find there is a big void in the  SharePoint solution development process, and its spreading more every day.

Luckily the cause is not difficult to identify, and having any sort of formal development experience (particularly in enterprise environments) the remedy is clear.

I believe that the cause itself arises from the very nature of the product, how its sold, how its perceived. The product itself, or its perception as “a product”, rather than a platform or series of services, leads most businesses to believe that it can simply be implemented out-of-the-box. While Microsoft and many others in the SharePoint community have stressed the importance of Governance, and Information Architecture (which have been very well perceived,) I find that that these topics simply aren’t enough. They help address many of the operational and organizational issues having to do with a successful SharePoint deployment, but do very little in regards to the functional aspects of the solution. As a result, the developers end up having to make many last minute decisions, the solutions aren’t very scalable (at least not from a functional standpoint), and become very difficult to maintain. In the short term, the developers and support personnel become very frustrated with the solution, in the long term nobody is happy.

The remedy is simple, and likely already in place in your organizations software development methodology. I find that almost every problematic SharePoint project lacks a clear definition and a design, this is where the real problem lies.

In one of my next blog posts (likely the following one), I will share with you some guidelines on what to include in your definition and design documents.

Added July 7th, 2008 – I’ve posted the follow up to this post:
SharePoint Solution Development; Define (Requirements Gathering) and Design Guidelines

Technorati Tags: SharePoint, WSS, MOSS