Blogs

There are many topics that can act as a lightning rod in a conversation. Religion. Politics. Tastes great, less filling. People dig in, want to be heard, and can talk on and on for hours. The same is 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 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).

Most folks have an opinion on all of this. You've had this discussion at some point with your team, or with management. The problem is -- there is no right answer. It all 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.

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.

What's your experience with the timing of involving end users?