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

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.

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

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

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.

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