The Penultimate SharePoint Answer

Christian Buckley

Christian is a 7-time Office Servers and Services MVP, internationally-recognized technology evangelist and collaboration expert, and the Founder & CEO of CollabTalk LLC, an independent research and technical marketing services firm based in Salt Lake City, Utah.

  • 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.
    .b

  • 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.