Sílim go bhfuil a lán againn i láthair ó am go chéile le, d'easpa frása níos fearr, riachtanais óg-leanbh. An t-úsáideoir deiridh i ndáiríre, an-dona mian le breathnú sonracha áirithe agus mothú, nó struchtúr sórtáil an-sonrach nó a ghearradh amach cliceáil amháin nó rogha roghchlár chun maolú ar loingseoireacht nó [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 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 a 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. Nó, 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.
</deireadh>
Lean mé ar Twitter ag http://www.twitter.com/pagalvin
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.
Mar sin féin: 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. Mar sin,, 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. Mar shampla, 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
Great point, Ruven. There is a fine line. I personally tend to “give in” rather than take a hard line. It always makes me uncomfortable when someone pushes back against client requirements twice and three or more times.
I almost always follow the “simple solution” approach you describe. I can’t actually think of one instance where it didn’t work out best in the end.
I generally agree with this post Paul. Go deimhin, I catch myself often saying to people “SharePoint can do anything you want it to do except what YOU want it to do.” I often try to find simple out of the box methods to solve an end users business need. As much as I love and enjoying developing solutions in SharePoint I’d rather try something simple and out of the box first.
Most times this lands up being enough and other times it generates a new idea for them that will make building a custom solution better for them.
Post iontach.
Paul Liebrand
Twitter: @PaulLiebrand
I have to deal with these requests very frequently. Luckily, often the business will acknowledge the request is a ‘nice-to-have’ rather than a ‘need’.
When it isn’t clear I start with asking what they are trying to solve with the request. That typically catches items that they simply didn’t recognize as a nice-to-have initially. Then I move on to evaluate what they are asking to determine if it is actually something simple or not; and what the impact scope is like (such as is this a change to a single sub-site or to the whole farm).
The greater the impact scope, the greater number of questions I raise. If the answers do not sound like a true need, but are still focused on acting like it is a need, then I present the time/cost and whatever impact that may be associated with the request.
If the business still wants me to go forward, I do, but we all have a much more clear picture of what is changing.
I’m new to your site but follow you on EndUserSharePoint. I work for a military hospital and know what everyone is talking about when it comes to “Can Do” and “Should Do”. I get this almost every day and the “Can SharePoint make documents not printable? Can we take away the ‘send to’ option?” The department would like to have some documents view only (no problem, done) because of the numbering and tracking system for the documents. I’ve been searching different blogs and sites and can’t find the answer. Hope someone can help.
Paul:
I think that the push back, or at least the discussion about the real utility of things, is what separates real SharePoint Professionals from plain developers. We can all make SharePoint do this stuff, like hiding the “View All site Content” link even though most people don’t see it anyway. It’s our job to help the client (internal or external, it doesn’t make a difference) understand which bits in SharePoint really are useful and why, why some UI things may actually be detrimental, etc. We ought to know better than they do and that is what we are paid for. If we simply acquiesce to every demand, then we’re only giving 50% at most.
Go raibh maith agat ar an bpost!
M.
Pingback: Steve Ballmer is a God; Why Google Won't Beat Microsoft in Cloud Collaboration; Adobe Brings Flash to Mobiles - SharePoint Daily - Bamboo Nation
Hi,
Thanks for the post and asking everyone to leave a comment for his experience, In these situations i used to give both option to the client, There is an easy to build/fast solution which gives you almost what you need but not 100% ( from performance, look and feel, maintainability..etc) and there is another custom solution that gives you what you want, present an estimate for both solutions and Cost associated to it, and then usually if the custom solution cost is higher they used to say let’s go with almost what we need :). Unless what they want is really affects the process and a highly demanded feature. I usually expect on those meetings someone will jump in and start discussing why ? and for your experience with the product you can convince him Why and How long will it take?
Tá súil Cuidíonn seo.