Part 1:

For almost 10 years I have always called myself a Functional Designer but because of my SharePoint specialisation it is time to change this role name to a more suitable one, I present you "SharePoint Solution Designer".

Below I will explain the fine details of this role.

SharePoint Solution Designer - SSD in short

In current and past projects I noticed that several companies skip one step when hiring people, they start with developers and forget to add people that safeguard the overall design. Potentially that can end in disaster. Developers are great and creative people (see our team) but sometimes they tend to focus on a few issues only. In a project it is important that the broader scope is guarded and that the first vision of what the product should do remains intact. You know how it works, problems distract people from the original goal and you could end up in a lost focus situation.

A SSD is a diehard SharePoint specialist with multiple years of experience with end users and the business. In most cases he is the trusted man for a SharePoint project leader (together with an architect) and he supports the project with all SharePoint related solution issues. That said, he is also the main designer of the SharePoint solution. In some ways he is a traditional functional designer but because of SharePoint he designs a lot in realtime (does not mean that he doesn't document).

Skill set

A SSD has the following skills:

• SharePoint front end specialist (not a Central Administration specialist);
• Focus on what the users need;
• SharePoint designer (webservices and DataView webpart);
• Integration specialist;
• Good verbal communication;
• Sense for business;
• Strong personality and a product vision guard;
• Management capabilities;
• Knowledge of features and solutions.

So how does this SSD approach a project?

First of all he needs to setup communication lines with the business, sponsors and project leader. Communication is essential because an SSD needs to grasp what people want and how they want it. During the conversations the SSD will try to collect as much user stories as possible to get a good understanding of the requested functionality. Later on these requests will be translated to real SharePoint solutions (out of the box or developed). Based on all this information he will build a very compact but clear document that transforms the user requests into a readable story. This document will be used as a starting point for the project. With this document the SSD and the project leader can make an estimate for time and budget. In this phase he also starts talking to an architect to see if the architecture limits proposed functionality.

My normal approach is to split up functionality into two blocks:

• out-of-the-box
• custom made

This is really important because for custom made you need real developers. Out of the box can be done by either the SSD (only a prototype) or junior developers.

Out of the box

The next step depends on the company and how they work. In some cases you need to build a complete functional design document but I prefer a POC in a real (test) SharePoint environment. Again, documentation is still needed. The SSD could start building a POC but in bigger projects he probably hands it over to another SSD or junior developer. The prototype is mainly used to showcase the discussed functionality. Be aware, because SharePoint is a fast point and click environment users tend to think that a solution is already finished, make sure you communicate this! The prototype will not contain any special made webparts in the first phase. In many organisations a prototype releases more budget because people get enthusiastic about what they see.

After the presentation of the POC it is really time to sit down and to process the feedback.

Custom made

Because SharePoint uses webparts (smallest building blocks) it is already possible to start building the basic foundation for all webparts. Things like:

• logo for the site- and site collection feature list;
• namespace and naming conventions;
• configuration;
• installer;
• source control.

In the earlier mentioned document the SSD has defined the custom made components (probably webparts). These need to be defined in either a technical design or a more detailed functional design. A good developer can build based on a very detailed functional design. We want a developer to use his own brains too, don't we?

Documentation

There is a simple reason why I build a POC first, it has to do with the screen mockups. A real SharePoint environment is really the fastest way to build the needed mockups. But, right after that the documentation and process and activity design should start. A process is how information flows and a activity is one part of a process. Nowadays I use a tool called Serena Prototype Composer.

As a SSD I build all the diagrams and documentation for the whole solution.

Managing development

While there should be a lead developer in all projects a SSD can help out with managing the developers. They need to be managed because they sometimes tend to add non-requested features (creative blokes) or lose focus. A SSD keeps an eye on the overall progress and requested features.

 

to be continued...