Functional consultants vs *great* functional consultants
Kristian Kalsing was written a really terrific post, not just because he quoted yet another bloody international standard that I will have to now read (ISO15489). But because, drawing on his experiences of the world of SAP, he has observed that there are some important lessons that can be learned for SharePoint engagements. SAP (okay, well Basis anyway) is a world that I experienced way back in 1999 and, boy, can I write some stories about social complexity and project failure about that era!
Kristian observes that on SAP projects, the roles of consultants are typically very clearly defined and discipline based. For example, there are infrastructure (Basis) consultants, developers and functional consultants. Even within functional consultants, there are sub-disciplines of expertise. (Hope you don’t mind me quoting you Kristian).
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.
Kristian observed that this notion of functional consultants does not occur in the SharePoint world. However, he qualifies this by observing that SAP is much bigger than SharePoint and therefore a direct comparison is "bit of a stretch", yet lessons can be learned. On the ‘bigger’ point I actually disagree and think that the context of ‘bigger’ is relative (and I look forward to Kristians’ opinion on my take). SAP and ERP systems are massively bigger and more complex than SharePoint – without a doubt. SharePoint may not be as big as SAP in terms of feature-set and complexity, but it can actually be just as big as an ERP system in terms of the impact on the day-to-day workings of staff.
To paint a gross generalisation, with an ERP system, often all that many end-users will ever see is a system to enter their time-sheets and perhaps perform some HR functions such as apply for leave or check pay-slips. Not everyone directly sees or interacts with, say, financials, plant maintenance and the like. But you can be pretty damn sure that everyone saves files to G:\ drive on a daily basis. (Substitute whatever your drive letter is that represents your jungle that is the file system).
More staff = more social diversity = more differing opinions = more complexity = bigger scope = more options = even bigger scope = wicked problem
Therefore, it is not a case that "lessons can be learned from the SAP world", but it is a case of "lessons should be learned from the SAP world".
But here is one additional (admittedly subjective) point to consider.
ERP systems have a really bad failure rate. Does the fact that there are discipline specific functional consultants involved really hold the key to project success?
Don’t get me wrong. I think that SharePoint functional consultants are a critical piece of the puzzle and, by god, the world can do without Microsoft gold partners throwing one of their "technical" people at what is essentially a project with a huge training and advisory component. But succeeding in SharePoint – or any other discipline involving complexity and a large diversity of stakeholders, goes deeper than that.
The difference between a "functional consultant" and a "great functional consultant" is not only domain specific knowledge. It is the art of helping diverse stakeholders to disentangle complex problems from a cluttered maze of overlapping issues, the moving target of requirements into an environment where all participants have a shared understanding.
I’ll have more to say about this as I delve deeper into the "One best practice…" series.
Thanks for reading
Paul Culmsee
I agree with the notion that SharePoint rollouts can potentially be as big as ERP implementations, if not bigger, from an organisational impact perspective. Although, this depends a lot on the type of organisation: Lots of deskless workers (blue collar) versus lots of knowledge workers (white collar). In a blue collar industry, SharePoint is often only implemented in head office but the ERP system rollout can affect every worker in the organisation. However, in a white collar industry, leveraging the SharePoint platform has a huge (and usually underestimated) impact on every person’s job.
This distinction might be about to change. We haven’t heard much about the Office 14 suite yet, but it looks like it’s certain Microsoft will expand their productivity platform to deskless workers by providing web-based versions of the Office apps, ideal for kiosks on factory floors, etc. A whole new can of worms when talking change management, so we better start finding and creating those *great* functional consultants. The evolution of technology is definitely running at a different pace to the evolution of people’s work habits.
Yeah thats a great point you make Kristian, SharePoint *is* very white collar focussed and something that I overlooked in my argument. I did Basis in 1999 (on AS400!) and recall that the main users of plant maintenance were blue collar guys out in the country on grimy old IBM unix workstations. But the white collar workers (myself included) had very little exposure.
I’m annoyed I overlooked that, since I’ve previously warned people that organisational culture has a very large impact on how you go about implementing a collaborative product like SharePoint. Vertical market considerations was going to be my next topic in that series.
You and your wicked problems LOL
you aint seen nothin yet… 🙂