SshhhharePoint

Many of my engagements with customers and indeed other consultancies invariably have an 'intranet' element within the requirements.

I remember a while back when SP2010 was released and many of use realised that demonstrating the OOB user interface was not the best approach; where the customers response was invariably muted and unimpressed.

So I have been considering how we approach SharePoint engagements and indeed how we could approach them with a more practical business approach rather than a technical one.

Many of us are 'techies' - SharePoint solutions architects, SharePoint solutions developers and so on.
Many of us are also heavily engaged in SharePoint presales and SharePoint customer demos.

One thing we all have in common to some degree is that we are proud to be 'SharePoint' people....we love the product, love the architecture, love its nuances and all of the rich business functionality that it provides.

So it comes as no surprise that when we engage with customers we engage with them with our SharePoint hat on.
We are going to solve our customers business problems, inefficiencies and overheads with a SharePoint solution....and we tell them that.

But should we take our SharePoint hat off?

The phrase or word 'SharePoint' has many connotations depending on who you engage with. In some information management communities it is treated as the black death, in others it is the fix for world hunger, world peace....you get the idea!

When a user fills in their timesheets then don't think 'My timesheet has been created by system X'.
So it makes sense that when a user interacts with their intranet or information management system they don't consider what system it has been created on.

What is important to the user is that it makes their lives easier, enables them to work more efficiently and to be more productive during their working day.

What is important to the business is more efficient users = more efficient business = cost reduction through efficiency.

So what is the best approach with a SharePoint solution for the client?

We should be engaging with the client without SharePoint specifics...rather with solution specifics.

Should the user care that it's SharePoint...absolutely not.
Should the user know that it is SharePoint ...it shouldn't matter what it is.

We develop our thoughts around a solution based upon SharePoint and that's a given as we are going to use SharePoint as our platform of choice.

But we often communicate the solution in terms of SharePoint but is that really the best way to present a solution?

Perhaps we should present the solution as a solution...I know that sounds obvious but in reality many of use stick our SharePoint hat on and start talking SharePoint solutions; SharePoint specifics.

Obviously this may depend on the level of engagement, but how often does a records manager, a CEO or an information worker have to know the underlying technology?

Sure the IT team will have a vested interest but engaging with the end users and information workers shouldn't require a SharePoint hat, in fact it may just muddy the waters.

Is that really SharePoint?
Does it really matter?