Lessons Learned on Getting Buy-in

Chapters 2 and 3 of the SharePoint Best Practices book I’ve been reading discuss the emotional aspect of getting people to “buy into” this new SharePoint solution you’re building. I thought I’d present a couple “lessons learned” from the projects I’ve been on myself, along those same lines:

• Unlike an e-mail client, where you can tell folks “Starting Monday you’ll be using Outlook instead of Lotus for your e-mail,” content-driven sites grow because many users contribute the content. Users will only be compelled to use it, if it’s easier to use, and more productive, than whatever they were using before. Therefore, it’s in your best intrest to build a compelling solution for their needs.
• When getting buy-in from your end users, it helps to build some enthusiasm. Users are much more apt to build what they feel like they have been a part of designing, rather than feeling coerced into using something. I was at a client where the project manager sent out weekly updates to the company about the progress of the new Intranet. He was going around to different groups, hyping the new site. When I introduced myself as the consultant building the new SharePoint site, employees responded by saying things like, “Wow, so you’re the one building it! We’ve heard so much about it. It sounds like it’s going to be great.” I guarantee you, the initial adoption rate by coporate employees at that company will surpass that of most companies who first roll out a project.
• Along those same lines, ask the end users what they want. This sounds obvious, but it’s not always, especially in scenarios where the solution is being “pushed down” from some high authority within the organization.I once worked on a project for a non-profit in an impoverished urban area, flying there every week for 3 months to build a solution (which had been architected before my arrival, I should add.) About a week before I was scheduled to roll off the project, the leaders of the organization (who had grown up in the community, but had since gone on to earn degrees in law, electric engineering, etc.) said, “Hmmm… this web site is going to be for people in the community” [who have little to no computer experience]… “I wonder if we should ask them what they want?” Needless to say, the site was never launched into production, and I felt bad for wasting thousands of dollars flying back when the community obviously could have used the money elsewhere.
• He who owns the pocket-book is not always the one wo drives the solution. In this situation, make sure you know who you work for. Different people can have different motivations for seeing a project succeed, and will thus potentially feed you different requirements for your solution.I was on a project where a project manager had managed a previous implementation of SharePoint that failed in many ways. An executive at the company brought our company in to work with SharePoint at their company. The manager who had originally overseen the previous failed solution was put in charge of scheduling our time and tasks. This person saw this as an opportunity to fix the previous solution, and make themselves look good to their boss in the process. However, after several months at the client, we discovered that the person who was paying our bills was more interested in using us for our architectural expertise in developing a larger SharePoint solution. However, this executive had left us in the hands of the other manager. So, we were spending our days writing solution packages and features rather than architecting a larger SharePoint portal for their company. This could all have been avoided if we had done a better job of figuring out whose interests we were serving from the get-go. (In my book, the person who pays the bills gets the biggest say!)