The Penultimate SharePoint Answer

One thing that is consistent across online communities is the ease at which we can take things out of context. Honestly, after a few conversations on Facebook around the latest local city council procedures took a turn down a dark path of religious bigotry and personal attacks, it got me thinking about the many topics that can act as a lightning rod in a business conversation — which, sadly, is not too far from what I experienced this past week on Facebook: Religion. Politics. Race. Ageism. I’ve-been-here-longer-than-you syndrome. People tend to dig in and want to be heard, but rarely take the time to listen — and much less time to actually understand other perspectives.

The same can be true for technology circles. For example: when should you bring in the end users for their perspective on your SharePoint strategy? Nobody disagrees (I think) with the idea of involving end users in the process, but people have some very strong opinions on the topic, most of which stem from the real or perceived lack of control that happens when you ask people for feedback rather than tell them your prescribed solution.

The question stands: when is the right time? If you bring them into the planning too early, there are impacts to the scope and design. In my experience, when end users are brought in too early, they see the new capabilities, all of the bells and whistles, and get caught up in what could be, and skew their thinking about what is actually needed. If you bring them in too late, there are also impacts to the scope and design. They may limit their requirements because they cannot fully envision what is possible, and worse yet, may close themselves off from future discussion because they’ve already told themselves that it won’t be what they want (and what the business needs).

I know that you have all had this discussion at some point with your team, or with management. The problem is — there is no right answer. To be honest, there are some solutions that never need to run through committee, like whether to use the Microsoft Office suite or to move to some knock-off brand. When 99% of the business world is using Office (don’t pester me with stats that show its slightly less….I don’t care. My point is that it’s the overwhelming majority), and if Office is what you’ve always used, and therefore all of your existing content and productivity artifacts are Office-related, is there really a question? But for most other technology decisions, there are many options, in which case the most correct answer is the penultimate SharePoint answer: It depends.

Part of the problem is that people have a tendency to jump to solutions before they fully understand the problem, or the scope of what is needed. We see this with developers who prefer to jump right in and start coding without fully understanding the business requirements. We instinctively want to solve problems. We’re good at solving problems. We’re just not good at getting the requirements right up front, which tends to impact the scope and design (and cost).

When designing and building a new enterprise portal, or a team collaboration hub, or an operations and business intelligence platform — whatever the plan may be — the initial focus should be to thoroughly define and understand the current-state (what is in place today, what is working, what is not working) so that the project team (and the business) has a clear picture of how the solutions should work before moving to the design of the future system, much less before decisions are made about which technologies to utilize.

That’s one of the glaring problems with SharePoint. We sell end users on the excitement of what could be, and skew their perspectives on what is actually needed. Or we don’t tell them anything about it, only that its being rolled out, and they react negatively — shutting themselves off from it, affecting adoption. Spend too much time too early focusing on new technology, and it may slow down the requirements and current-state documentation process. By waiting too long, and not getting them involved until after the future-state planning and design process, end users may reject your solutions, feeling left out. Just remember — end users who participate in the design of a system are more likely to support that system.

The key is to engage with them at the right time, after they’ve been able to articulate their business needs, but before they’ve become married to any particular solution. You need to have a plan for when and how to involve your end users. Do this, and you’ll have them engaged and on-board with your plans. Or, at least they’ll be a bit more understanding about the tradeoffs being made.