Blogs

If you develop systems for any length of time, you get a feel for the line that divides “what we need” and “what we want”. If you perform this type of development long enough, you will realize that we aren’t talking about a boundary condition, but rather a cyclical relationship. Ignore what people want long enough, and you will find your inaction affecting what someone needs, usually when they tell you they are going elsewhere. When it comes to developing solutions in SharePoint, the line between wants and needs is wide and fuzzy.

The reason for the ambiguous value of a SharePoint project is the nature of SharePoint. While you may be considering a solution that solves one problem, the fact that all the components can be used in other processes and in other ways, adds a few variables to the value equation. When you look at the things you are building in SharePoint, you have to keep asking yourself “what else is this good for?” and “who else might be able to use this stuff?”

Application development is all about discrete systems or possibly related systems. SharePoint is about building an environment. One of the reasons companies buy SharePoint is because they can do so much with it; Content Management, Collaboration, Scheduling, Social computing, etc. – we’ve all seen the pie. If we end up building discrete solutions, we are not doing the platform justice.

We are working on a “system” to track the time spent on various projects. In order to make that task easier, we need to be able to choose the projects. We could use a Choice column, as these projects don’t change that often. We can also use a Lookup column based on a separate list. When we started asking people for input, we discovered that people in other departments are interested in referencing these same projects. For example, while the system was designed to support accounting allocations of time, the list of active projects can also support tracking travel costs. Supporting additional requirements might mean a few extra columns in these lists, but that’s when we really start cashing in on the value SharePoint brings to the party.

To avoid the cycle of doom I mentioned at the start, we have to use a cyclical process. As we investigate requirements and build out our design, we have to march that design back around to all the players. SharePoint development requires communication with more people and more frequent communication with those people. You also have to explain the changes in layman’s terms. By telling people what you changed or added, and how someone else is going to use the result of that change, you get them thinking about the ways they can use the new information, and new ways they can use the existing information. Until people are truly comfortable with the depth and breadth of SharePoint’s feature set, it remains our job to call attention to it.