There has been lots of debate lately around why SharePoint projects fail and what’s currently wrong with the way SharePoint implementers engage. Paul Culmsee has written a landmark post about the criticality of user understanding as an important prerequisite for user engagement. Jeremy Thake has a great wrap-up of how the industry currently works. And then there’s all Joel Oleson’s work around governance and best practices which is also highly relevant in this context. A lot of the issues boil down to a lack of understanding SharePoint for what it is and in particular taking the users along this journey of shared understanding. The question is how do we change our approach to accommodate this?
I’ve spent the last 12 months in the world of SAP. On SAP projects the roles of consultants are typically very clearly defined. Not only is there a much clearer distinction between infrastructure (basis) consultants, developers and functional consultants, but the functional consultants themselves are very specialised in different parts of the SAP system. The role of the functional consultant is to work closely with the business to determine the requirements, configure SAP to meet those requirements and provide knowledge transfer to the users. To be able to do that effectively, the functional consultants are required to have the relevant business experience.
The point is that the consultant configuring the finance module is basically an accountant and the consultant configuring the HR module probably studied human resources at university. In the SAP world, it would be absurd to take someone who has configured materials management or plant maintenance with one client and ask them to configure HR with the next. In SAP, the specialisation does not stop with the functional areas of the product. There are also functional consultants building up experience in certain industries. E.g. supply chain management can be very different when talking coal mining compared to running supermarkets.
In the SharePoint world, we often see technical consultants one day building an intranet for the marketing department in a bank and the next day they are configuring Excel Services for the financial controllers in a mining company. Isn’t that ludicrous if you really think about it? Although drawing parallels between the worlds of SAP and SharePoint might be a bit of a stretch considering SAP as a product is humongous compared to SharePoint, I do believe there are some lessons to take across.
What if we had the concept of SharePoint functional consultants? Consultants that did not necessarily have a technical background but were business experts specialising in for example collaboration, business intelligence or enterprise content management. They would first of all have business experience in their respective fields and then be trained up in configuring SharePoint functionality to build solutions. When they do reach the limits of what the product can do out-of-the-box, they would request feature development from SharePoint technology specialists and developers.
The functional consultants themselves would spend the majority of their time developing their expertise in their area of specialisation. A collaboration consultant would understand the issues arising from people working together and the business benefits of effective collaboration. An enterprise content management consultant would have real-life experience in document management and understand the requirements of the ISO15489 international standard on records management.
So, isn’t this why we have business analysts? SharePoint implementers do sometimes engage business analysts to work closer with the business in analysing and specifying the requirements. Whilst this is great for defining scope and mapping out immediate needs, the analysts do not usually help to bring about the shared understanding of SharePoint with the users. Because they don’t usually get involved in configuring SharePoint, they are rarely effective at communicating the real benefits of SharePoint as a platform.
In further defining the SharePoint functional consultant, what we need is a role with the business knowledge and analytical skills of the business analyst, but with far more functional knowledge of SharePoint. They must be able to build solutions through the UI, but not concern themselves with the technical aspects of SharePoint. A SharePoint functional consultant would take care of the functional configuration which includes lists, libraries, content types and basically anything someone with site collection owner privileges can do. This is not to be confused with non-functional configuration which includes web applications, load balancing, backup processes and the many other tasks requiring farm administrator privileges and which is carried out by SharePoint technical consultants.
So maybe it is time that we start thinking along those lines and develop the concept of SharePoint functional consultants? I have come across a few people that seem to fit the bill. However, there are not many of them and they never work for the implementers. They are typically ambitious people from the business that have learned to configure SharePoint by trying to address their own pain points with it.
