19 February, 2009

Do we need SharePoint functional consultants?

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.


Liam said...

Very intersting. I tend to agree with what you're saying. Something that comes to mind however is the consideration of the target market for each product. deployments are typically for large organisations with allot of money to get it done right. MOSS deployments can tend to be for much smaller players with a much smaller wallet...

Erica Toelle said...

This post is right on the money. I've been working in this role (SharePoint focused business analyst) for the last three years and while people understand the value they don't understadn what exactly I do, which is gather requirements while helping people understadn SharePoint. Please let me know if there is anything I can do to help the cause!

Jeremy Thake said...

Great post mate. Great to hear it from someone with experience on another platform...which is hoping why my post would trigger. Functional Consultants are exactly what we need and I would go as far as saying that they need to focus on particular areas such as BDC, Excel Services, InfoPath etc. as well as overarching solutions.

Øyvind Nordnes said...

I agree, bridging the gap between the business needs and the technical solution is very important to succeed. In my opinion, the value of having someone that understands the business, and is also able to communicate this efficiently with both the business and the technical side must not be underestimated.

Paul Culmsee said...

Posted a reply to your excellent post mate and looking forward to your feedback


Henry Ong said...

I also see the same trends that you see...you've taken the words right out of my mouth! :)

I have always stressed to all my clients that to be able to extract the full value out of their SharePoint deployment they really need a very technical SharePoint Business Systems Analyst that knows how to stretch the system as well as being able to implement elegant solutions that can be often times done out of the box. And this often times requires that this person has specific business experience in the different business functions that you have mentioned.

Misty Khan said...

Excellent point, Kristian, regarding using functional area experts for implementation. I find this is a pretty common issue with using a traditional IT support company for these types of installations - their area of expertise is IT support, not sales, hr, etc. I also agree that there is not a good understanding out here in general of what problems SharePoint is meant to solve - I've been struggling with one such issues myself - see http://arrow-tips.com/archives/395. THanks for this post and for comment on my last post - very helpful!

Veronique Palmer said...

An interesting perspective, I will take it up with my business users as see what they think. Thanks. I like the idea.

Christophe said...

Unfortunately it's not that simple.

Applications like SAP have a set of weel defined core features. Functional consultants on a specific module, like FI or CO, have common references.

SharePoint is a Jack of all trails and OOTB only offers basic features. So either you stick to the OOTB features, in which case you can't really talk about expertise, or you start looking at specific developments and third party tools, in which case the consultant's expertise is not easily tranferable to another company.

Judy Price said...

Fabulous article Kristian, thanks for providing the link to your article.
In my current and previous Sharepoint roles, I would regard myself as a Sharepoint functional consultant. My specialty is ECM and collaboration.
It would be great if business and recruitment agencies started to look at resourcing in this way and I think they would have alot more success in matching the right resource to the right role.

Kevin DuPriest said...

In a military command especially, the task of implementing SharePoint is given to the A6 (Communications) a group of network and system administrators focused on establishing Active Directory, OS, SQL servers, Exchange, etc. So it's only logical to task them to stand-up a SharePoint Portal. Right? But only from a technical implementation, not business process.

A few hours of farm and network configuration, and your ready to add content. Most military commands fight with internal connectivity issues, one base-one network, firewalls, email hosting, AD accounts, software approval process, NIPR/SIPR authentication etc, but NEVER... NEVER has an A6 group EVER gathered business process requirements for their functional or operational areas of the Command, from the beginning.

Of course, they have explored all that SharePoint can do for their group, and have evolved their site and internal processes. They have developed code and web parts based upon their perception of a certain process.

Then the AFTER THOUGHT... let's get some SME's in here and address our business process issues. Of course the SME doesn't know SharePoint, and the System Admin from A6 doesn't know their process.

It has been a difficult learning curve of an A6 or even CJ6 group to go outside their Knowledge Management group and gather core command business process in meeting functional and operational processes.

While in Iraq, working for MNF-I, we switched the task of functional implementation of SharePoint to the Chief of Staff. The head office determined what functional areas needed to built in SharePoint and CHAMPIONED the group, tiger team, charter to make it happen.

It is so much easier to gather requirements when you are directed to do so from above, rather than requested from someone outside your group. Operations, Intel, Analysis, Manpower, etc... they have their own jobs to do... why should they help Communication stand-up a web site?

Great forum, excellent topic.

Kevin DuPriest
"Functional SharePoint Consultant"

Marijn said...

I myself am also working in this role. Mostly I also take the job as a Project Manager (for smaller projects) and coach, trainer, functional support, SPOC,... besides being a functional/business analist. I am sure that this role adds a huge benefit to the customer and on any project!

india said...

I completely Agree with it.I am working on sharepoint for last six years as developer,administrator,technical project manager...after three years I realised the value of having business\functional knowledge..so last two years I did MBA in marketing and IT...I conduct sharepoint trainings and I reiterate this point to sharepoint developers and clients too in my blog http://sharingpointer.blogspot.com/

Lester Mcmillan said...

SharePoint consultants assume a lead part when coping with client engagements. These specialists further do a project independently.