Stop being so damn polite! Tell them what you need.
I was working with a client this week, drawing out what a good solution would be for a project she was working on when this statement came out, “Oh, just do what’s easiest.”
There were three people on the call: the site admin who will implement the solution, the end client who needs the solution, and me to lead the discovery process. We were talking about a small solution that needs to hold a couple hundred documents. The discussion was centered around how people will find the documents once they have been placed in the repository. The documents need to be displayed through web parts in specific areas of the site. The site has sections and each section has multiple pages.
As we discussed the structure of the library, everyone realized that “Section” and “Page” would be useful when deciding how to expose the content in the appropriate area. That’s when the “do what’s ever easiest” comment came out.
The site admin who was in on the call said “OK” at that point, and moved on to another topic. Before she could do that, however, I started hollering, “Whoa! Whoa! Hold it right there. It has nothing to do with what’s EASIEST, it’s about what you want!” Sheepishly, the client said, “Well, I really would like both columns.”
Where did this come from? Why did the real desire almost get passed over?
Reponses like this happen everyday during a discovery process. It’s important to listen closely and hear the real needs of the client. Sometimes the clue is when there is a hesitation in the response, when someone thinks they are making something “easier” by letting things slide. I think this comes from being too polite.
We are taught to “work with people”, “see both sides”, “bend a little”. In the case we are speaking of here, that’s not appropriate. You, the client, have the right to express exactly what the outcome of the solution should be without consideration of the technology or the person implementing the technology.
Yes, I know, we all want to be polite and recognize that everyone is over worked and noone really has time for “our little project”, but that defeats the purpose. If you’re asking for a solution, we want to know what you REALLY need. Don’t be concerned about hard vs easy. We’ll let you know if that’s a problem.
My suggestion? Quite being so damn polite! Tell us what you really want and stick to it. Everyone will be better off for it.
I **want** all 50,000 of your monthly readers to follow me on Twitter @buckleyplanet
Having said that, great post, Mark! I’d like to add to it by telling business users and end users to INSERT YOURSELF INTO THE DISCUSSION around SharePoint. They are the ones who know the business processes, they are the ones who know the content, and they should be very vocal about how SharePoint is shaped because they’ll be the ones using it! As SharePoint gains more of a footprint within an organization, it is critical that end users stand up for the systems and processes that they own, otherwise they’ll be stuck with someone else’s interpretation of their needs.
Thanks for telling me what you “want”, but that’s not necessarily what you “need’. I’m having that discussion with my 8 year old and 5 year old since it’s that time of year. Christian, you’re too old for Santa, so I guess you know where this is headed….
Mark
Thank you, Uncle Scrooge :-)
Also consider the fact that years of being told “No” by IT is hard to unlearn. Those of us who work with Sharepoint can start to change that, but it takes time. The answer should almost never be “No”. It should be something like “Well, let’s think about how we can make something like this work” or “What if you got this part now and this other part later?”
When you’ve been hitting your head against the IT wall for years, at a certain point you just quit. It’s not necessarily politeness.
M.
Yes! I agree completely Marc. Our corporate HR Vice President constantly preaches, “Yes, if…” When someone’s asks a questions, never say no, rather “Yes, if…”
Marc is spot on!
Let’s be honest most IT departments, especially in large organisation, are not staffed by the most personable of folks. The combination of always saying no and end users not knowing the power of SharePoint means that the situation described is often the case.
This is probably one of the biggest reasons business users eventually stop coming to IT for assistance. Several of the clients I work with often have 3rd party solutions that were brought in to solve a problem that IT was unwilling to help solve. In one client, they had at least four different products for managing projects. This leads to higher support costs for IT and the continual spiral downward.
A previous co-worker of mine used to always say, “Technically, the answer will always be yes. We can do it. Practically, let’s make sure is brings value to the business. So I ask, should we do it?” This often lead to great discussions that helped define what the client was actually trying to solve.
I admit, as a solutions implementer, there are times when I would rather do the “easy” thing, but let’s face it — if I don’t get the business requirement correct in the first place, I will either be re-working it or the client will go find something else to solve the problem.
That’s always the juggling act: quickly meeting the needs of your users while also doing what is right for the business. These two things are not always at odds, but, generally speaking, the “what can solve this quickly?” is almost always at odds with “what is the right thing long-term?”
Running an operations engineering and PM team at Microsoft, I was constantly fighting this battle to give my org what they needed to do their jobs, but at the same time I felt pressure from the management chain and other organizations to centralize, simplify, collaborate. End users need to be aware of this battle, and realistic about what can/should be done to meet their needs. It’s one thing to be heard and persistant in getting your requirements met, its another thing to ignore the bigger picture (and an IT team that may not be calling the shots).
It’s interesting.
As a business analyst often I am responsible for controlling scope of a project and so at times I have to artfully say no. Such as the Yes… if scenario mentioned above or many of the other ways we can approach putting something off the table or out of scope for a period of time. It’s a part of the BA core skill set (or consultant skill set).
I think a big part of it is that we want to make sure 1) we really hear the request out (regardless of what stage things are at) and 2) that the requesting persons confidence is not shaken. When I say that their confidence is not shaken I mean in both IT (or whomever is managing the request) as well as in their own opinions, observations and most importantly that bringing up requests is a worthwhile exercise (confidence in the request process itself).
There are many ways to achieve this. Most of them involve explaining things as clearly as possible to the requester and ensuring there is a clear record that the request was made and that the request (even if denied) was appreciated.
Even as a management philosophy we should always encourage contribution and participation. I think sometimes in the pressures of the moment that these are long term relationships we are building and working on with clients, colleagues, or fellow employees and that just like there is no such thing as a bad question, there is no such thing as a bad request/requirement. There are just many that aren’t applicable, feasible, or actionable (based on degrees of uncertainty).
Seems to me it’s my responsibility then to holler “Whoa!” when I see it. That’s what actually happened during this encounter. As it stands, the library has been stood up and it is working the way it was intended.
I hope people can use this example as a way to step back and say “This is what I REALLY want.”. Yes, politics and personalities will always play into, but encouragement from us might help push it a little farther.
Mark
Personally (and this is from many years of retail experience prior to entering the IT field), I dont ever like to use the term “No” when speaking to a client about a possible solution. Instead, I’ll generally use something like “Here’s what we can, or may be able to do”…it’s has a more positive tone, and as others have mentioned already, takes a step in different direction than the normal IT response of “NO!!”.
Gathering all needed and required information in a client consultation is always an interesting venture…many times, they dont even know what it is really that they “Need” in order to meet their goals. They may know their “Wants” or “Desires” to deal with the situation, but most often, their actual “Needs” will always come to light during the conversation if we (I, you, all of us that are filling that “Consultant” role at the time) can help direct the conversation towards that as a goal. If you are a solution provider, then you are also a “Fisherman”…and the only way you can “Land that fish” is if you use the proper bait and technique…and for us, that “Bait” is the promise of the end result, and the “Technique” is the manner in which we get them there – both of which rely on us helping to steer the conversation in a way in which the client reveals everything needed up front (including those things that they may not have even known were neccessary beforehand).
uh oh, let the reqs roll in
While I agree with the principle of not immediately saying “NO” I have found that there are absolutely going to be cases or instances where that is exactly what you have to do in order to bring someone around after you have shown them there are better ways of accomplishing their request within the context of SharePoint.
Example; I recently implemented a system to track contract requirement request submissions. The initial set of information they wanted collected consisted of 36 items (or columns) for each request submission. After building that out in a list they came back and wanted an additional 68 items (one for each step in the process so they could track the requests whereabouts at any given time) added to the list which gives us 104 items per request submission in the list.
I explained several times that while I understood what she wanted there were better ways to accomplish the task and that few people, if any, are going to fill out a form that consists of over 100 fields.
I provided no less than 5 different proof of concepts to them that would have kept the number of columns in the list down to a manageable number but the Division Manager was dead set on having every individual item in it’s own column no matter what alternative she was presented with or what explanation/justification I gave her for keeping the number of columns minimized.
I finally had to tell her “No, we cannot, and will not, do it that way”.
After I told her no my boss made her choose from one of the provided proofs of concept and the group is now happily chugging along tracking their request submissions with minimal effort.
If you end up having to say “No” at some point be able to justify why you’re saying “No” and provide the requestor with multiple alternatives.
Of course it doesn’t hurt to have a boss that backs you up either.
All very good points but there is one more thing that I use when I’m getting nowhere. I try to ‘turn’ it around and let the section or department think it was their idea. I ‘feed’ them little information and try to guide them in direction. When I get a request/work order I go the enduser and ask “What is the process of doing your job and what do you want to accomplish?” It is the enduser that uses SharePoint every day. Management should take a more ‘active’ roll in listening and not just hearing what is need to accomplish their mission.