“Can Do” versus “Should Do” in SharePoint Projects
Author: Paul Galvin, Microsoft MVP – SharePoint
Paul Galvin’s SharePoint Space
I think that many of us are occasionally presented with, for lack of a better phrase, young-child requirements. The end user really, very badly wants a certain specific look and feel, or a very specific sorting structure or a cut out one click or menu option to ease navigation or [insert passionately held belief that happens to be wrong]. As SharePoint pro’s, we can generally meet almost any kind of requirement with the platform, but for some of them, we know in our hearts that:
- They are going to take a disproportionate amount of time to implement (and therefore cost more)
- They are going to be highly custom and therefore difficult to maintain and troubleshoot
- There is some easy SharePoint approach that meets 80% or more of the requirement (i.e. meets the sprit of the requirement, but not the letter of the requirement)
Bottom line, we know that the “requirement” is really just nice to have or even legitimate in some sense, but something that people should live with rather than spend a lot of time trying to “solve.”
I think of these as “young child” requirements because I’ve seen this pattern many times before. Kids will pine away and nag you for some new toy for weeks at a time. You get them the toy, they play with it for a few hours or days and then put it down, never to pick it up ever again. Or, you don’t get the toy, the nagging stops and the kid moves on to become President of the free world. I’ve seen this happen in SharePoint projects. Decision makers either get what they want and it becomes an unused or underused function or they don’t get what they want and the project still succeeds anyway.
I was reminded of that today in a forum post and I liked how Clayton Cobb tried to get the forum poster to push back on one of these kinds of requirements: http://social.msdn.microsoft.com/Forums/en-US/sharepointinfopath/thread/af8a1941-92ad-4f1a-b1bf-875e28ea79b7/
I’m really curious how people view this topic and how you deal with it. Am I missing the point? Do you have strategies to steer decisions makers away from overinvesting in trivial requirements? Please leave a comment.
Author: Paul Galvin, Microsoft MVP – SharePoint
Paul Galvin’s SharePoint Space
Paul is a Solutions Architect currently working most closely with Microsoft Office SharePoint Server 2007. He was recently awarded Microsoft MVP – SharePoint status for his work with the SharePoint community.
“overinvesting in trivial requirements” is a great way to sum it up.
I see this every day and pushback is difficult sometimes. Culture makes a HUGE difference. At larger organizations it seems techies panic to implement higher manager’s vision, without any real two way dialog about what “should” be done.
Grand vision of features, without concern to scaling and support, often leads to a pretty demo short term. Then long term lost emphasis, visitors, or the “unexpected error” page. =)
I work for a Fortune 100 company and see this all the time. What typically helps the conversation is putting a dollar value and listing out how support/SLA’s will be impacted. For example, if we do this now, it will cost 1000 developer hours ($90k) to redevelop when we upgrade to SP 2010 and may delay the upgrade. It may seem like a scare tatic but these customizations add to the complexity thus impact everything downstream. Vanilla as possible.
Another way to look at this is to encourage end users to think about the outcomes they want to achieve, not specific “how to” features. Often, when presented with the cost of a “requirement” (trivial or otherwise), users will be able to think about what they are trying to enable in a way that is less costly to achieve in the platform. I have several posts about this in my blog because the scenario you are describing is something I see pretty much every day! Here’s a link to one: http://www.networkworld.com/community/node/18529. I often tell my clients that they get to describe the outcomes but only the SharePoint pro gets to translate the outcomes to requirements. I can’t say it always works, but talking about outcomes or objectives rather than requirements gives you an opportunity to change the focus towards a more cost effective result.
My past experience tells me that you are correct: The desperately needed requirement is often quickly discarded, usually because it is not well thought through. I agree that it is our job as consultants to help steer the client towards a successful solution, not just fulfilling a requirement.
However: We don’t understand our clients’ business as well as they do. It’s important that, as consultants, we don’t become arrogant, telling the client that their requirement is unneccessary. So, we have a bit of a tightrope to walk: Help the client think through the resons for a requirement; explain why you would like to suggest another course and offer alternatives. For example, offer to start with a simple solution which can be enhanced later if it turns out not to meet the need.
As with most things in life, finding the right balance can be tricky, but is worth the investment.
-Ruven
Well said Ruven. I agree with you completely.
This is interesting reading – I’m faced with these ‘young-child requirements’ on a daily basis. Sometimes it gets difficult to remain calm when someone wants some ridiculous, tiny, non-functional thing changed that would take absolutely ages to do and add no value – and then declares that SharePoint is rubbish when you tell them its not going to be feasible :(.
Ruven’s point about it being our job to steer clients to a successful solution, not simply fulfilling requirements, is a very good. I think I might use that one :).
Yeah, I’ve seen the young-child behavior too. If a user deigns to make a feature request, you really gotta step on them right then and there. Roll your eyes, snatch the proposal from their hands, and with a heavy sigh say, “we’ll take a look at it.” Then several weeks later tell them what you decided in the first five minutes — can’t do it. “Our system doesn’t won’t accommodate such a change,” you should say, or something equally obtuse. Of course, if the requester is high up in the food chain, more finesse is required. But you get the idea.
And for heaven’s sake, don’t get drawn into a conversation about alternate approaches, more cost effective solutions, and things of that ilk. Users, like children, should be trained from day one to take what they’re given and be grateful to have it. They can’t possibly know what they want or need, and there’s not a single one of them who can do what you do. You’re the grown-up in this situation. You need to tell them the way its going to be.
Yep, young child behavior abounds. Just not all of it is on the end user side.