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.
Bjorn, you should read that sentence in context. I’m not stating that its right or wrong, just using a literary device to illustrate the impacts surrounding the early versus late involvement of end users. I agree that end users should be involved early and often — which is well documented in my writings. So while I appreciate your lengthy response, you really got wound up over nothing.
As always, Christain, you’re wrong 😛
You mention that involving end users or any user really early in the process leads to feature creep. That may be right, but it also a vital part of the overall SharePoint adoption. More importantly, it is a vital part of any scalable architecture.
When I work with requirement gathering as an architect, I always ask the client or users to ignore any limitations in budget, technology, or time. I ask them to imagine a Harry Potter type magic wand that can give them anything and then ask them to describe their perfect system.
The result of this exercise is more often than not that clients get a much better understanding not just of what they need right now but what they may need in the future. It gives me as an architect the knowledge I need to design a solution that take into account not just the needs now but the wants of the future.
In the end, it is I, as an architect, that needs to evaluate feasibility. Among the members of your normal SharePoint team, only the architects know whether building a certain solution is feasible with the resources available. The client certainly doesn’t know the developers and whether building a solution takes two days or two years and the developers certainly don’t know whether a balance sheets needs to be sortable or groupable.
You also say: “We see this with developers who prefer to jump right in and start coding without fully understanding the business requirements.”
Feature creep isn’t a problem; a good architect knows that new requirements come up all the time. In fact, good development practices mandate that you adjust frequently and rapidly (Agile) rather than try to come up with the solutions upfront.
Imagine, if you will, a client seeing an early draft of a solution and coming up with a brilliant idea for how to save the organization time and money. Sadly, you can’t really change your requirements anymore so now you may end up building a solution that doesn’t take into account these new requests. In the end, you may prevent your client from achieving new goals because you’ve developed yourself down a one-way street.
I know, in a perfect world, every decision is reversible and from a technical perspective, that may be true, but maybe not from other perspectives like business rule decisions. Also, in reality, building a completely scalable and flexible model is extremely costly; I’ve done that a few times on my own dime (SP SIN for example) and it’s a helluva challenge to account for things that nobody has thought would ever be a requirement.
So, the TL;DR version is that you should include your users and clients early and often, during all stages of a project, right up until they’re ready to hit the “deploy” button. Developers are or at least should be comfortable with this as it is a well-known method of development. PMs know this too, or should, for the same reasons. Architects don’t really care one way or the other.