I got a call from a friend who was working with a client.
The client wanted him to set up SharePoint. Unfortunately, they didn’t have anything more specific than that as a requirement. He got the impression from the client that they expected SharePoint to just work, to do things just by virtue of having been installed, with little thought to the fact that configuration would be required for SharePoint to actually do much of anything, and that there would be ongoing need for administration. They had so far been dismissive of his attempts to convince them that “Just set it up” wasn’t an adequate strategy for deploying SharePoint successfully.
His question –
How can I help them understand that what they are asking for is likely to end in failure, if they don’t take configuration and ongoing administration into consideration?
I was able to provide a few pieces of advice on approaches to getting the needed information:
First, SharePoint had already been implemented in other parts of the organization. This provides an opportunity to have a discussion around what features this department had heard about from the rest of the organization that had convinced them they needed SharePoint too. Finding that out will be a pretty accurate guide to what they need and the challenges they face.
Second, he could have stakeholders meet with him for a “features review”, to go over the things that SharePoint can do for them, and use that to determine what things they wanted and discuss the configuration and maintenance needed to achieve those goals.
Third, find out who their in-house SharePoint talent is. Anyone in the organization who has some experience with SharePoint may shed light on the actual requirements, and may have some leverage to get management to understand the complexity of their needs. Meeting with them and determining their competency level may also provide insight to how much help (if any) they will need once SharePoint has been set up. If they are going to be over their heads, preparing them to know when outside assistance will need to be called in might be a good tactic.
A fourth option occurred to me today – a meeting to define success metrics. The business side tends to like words like “metrics”, and it may make them more amenable to discussing and defining requirements and coming to an understanding about the resources needed to fill those requirements.
All of these approaches are just different tactics to get to the same information, ways to get past the barriers in the minds of the stakeholders, preventing them from seeing and addressing what it is going to take to achieve success.
Have you ever worked with an organization that wanted you to “just set it up”, without providing clear requirements and probably lacking a clear understanding of just what they are asking for? How did you handle it?
Get Notified! Scroll to the bottom of the page to get notified when new posts are added to the site!
The SharePoint Therapist 
I agree wholeheartedly! So many clients just don’t understand SharePoint. They have a vision but cannot translate it into a SharePoint format. For example, wanting “buttons” for 15, 30, and 90 day reports instead of entering a date range. Wanting to use the space below Quick Links for a simple changeable blurb (not knowing it goes into the masterpage), wanting to upload a document that gets the summary paragraph published into a web part, allowing external users (non-site members) to join meetings and collaborate on document editing and accept tasks, and buttons, lots of buttons!
The first thing I do is a little familiarization training to get them familiar with libraries and (especially lists and using them as forms), landing page possibilities (published vs team vs whatever), and groups and their permissions. Then and only then can we talk about what they want. It helps a lot to put it in a SharePoint framework. It also serves to open the door to a lot of ideas from the client on what they can do.
I believe this education is necessary to achieve the first and most important step – planning what you want to accomplish and how to architect it. Starts with Needs Analysis, then gather Requirements and design layout and functional flow ideas and then give then build a sample. Once everyone is on the same general page, you can start building the site collection(s).
Get the stakeholders and users speaking “SharePointese”, and the site begins to come together without surprises or going back to the drawing board to accommodate something new. The client has a good idea what to expect and your team knows what expectations they are working to meet.
Absolutely, you hit the nail on the head!
In my experience, I get the same behavior from many of my clients. However, mapping their requests to “easy wins” by using OOTB features often gets us a quick start, and greater likihood of the client accepting other “shortcuts” and discussions that I may recommend. It also gets us (1) into a Agile Iterative approach, where I get more user questions and brainstorming about what the client really wants, and (2) fewer one-man dictatorial pronouncements like, I want this and I want it this way!
I like your monikor — sharepoint THERAPIST — because I often describe one of my many hats as Psycologist or Marriage Counselor. If somebody objects, I need to discover why, and either adapt the solution or overcome their objection, recalcitrance, or outright oneryness. Many times I am just bridging gaps between different groups and getting them to cooperate. You can lead a horse to water, but you can’t make him drink. Likewise, installing SharePoint gives people the power to collaborate, but you can’t make them share!
-mrkcc
Most of my client don’t really understand SharePoint because they don’t care about SharePoint. Throughout my SharePoint journey, I never explain to a client what SharePoint does till I get what that client is facing with their businesses day-to-day. Business users these days only care what they can use to quickly complete their work, or solve problems.
You instead should get started with business problems, challenges through organization and then have an IT roadmap before thinking of SharePoint.
SharePoint is NOTHING.
By the way, I strongly recommend people reading “What business really wants from IT – a collaborative guide for business directors and CIOs” book written by Terry White. This books shows many aspects as to why deploying technologies has failed in business user’s eyes. It also gives an insightfully comprehensive guide to tackling the matter.
Totally agree that when introducing SharePoint, one should focus on business alignment – what are the problems, challenges or opportunites of the business – and work form there. In this case, however, the consultant was brought in expressly for the purpose of implementing SharePoint, but not given sufficient information about what Sharepoint would be for, what problems they expected SharePoint to solve for them, what their expectations of SharePoint actually were. Instead, he got “Just set it up for us.”
The post is about ways to break through that mental wall of “It will just do… stuff… for us once it is set up”. The client is already onboard with SharePoint, it is just unclear why, and I am not even sure the client has a good understanding of their expectations, much less what those expectations mean in terms of configuration and management.
I think the bulk of “installations” are like this. SP is not software you install. It is not a magic mind-reading solver of all things. It’s one of many possible tools you take in hand to fix what is wrong with your business. Therefore you have to have already decided that something is wrong, and be able to articulate it to those various providers of tools so they can help decide which one may suit you best. It does not- and cannot- work the other way around. However that is almost always how it is attempted.
Nancy –
Do you have any experiences getting clients past the “magic mind-reading” mindset, to where they can articulate what is they are expecting?