Those Four Little Words

In my life I have managed to upset enough people with just a few words. Well, sometimes it is more than just a few. And other times it is how the message gets delivered. But in my experience there are four words that when spoken, no matter what the context or tone, they will more often than not make someone take a defensive stance.

“Show me your requirements.”

I swear you would think I would have slapped someone across their face with wet bacon. As soon as you start asking for requirements the other person has only two real options. One is to go and get them. Two is to get mad at you for asking. There is little room in between. It is almost the same reaction when I try to explain to my five year old that there is a difference between ‘need’ and ‘want’ whenever I hear “Papa, I need to play the x-box.”

Known Versus the Unknown

Let us consider the following Venn diagram. If you were to think of all possible knowledge in the Universe, you would tend to divide information into two sets: things you Know and things you don’t Know. However, there is an intersect between those two sets, resulting in some enlightenment for yourself that there are things you Know that you don’t Know. And all of that sits on the higher plane of items that make up all the stuff you don’t even Know you don’t Know.

Got that? Great. Let’s continue.

What this means to me is that you cannot allow yourself to get upset when things change (because things will always change). In fact, a wise man once wrote that there is nothing permanent except change. You need to learn to embrace change as a natural order of things and do your best to not let change control your actions.

I often hear about having a “mind like water“, something that is usually talked about in a martial arts context but can easily be extended to having mental discipline for everyday modern life. So, how do you achieve this state of mind? Well, one way is to document as much as possible. But do not just document the things that you Know, start documenting the things that you don’t Know.

Crazy, huh? How can you document something you don’t know? Simple: just start asking questions. “How does your system work?” is a good one to start with. For a DBA it could be something like “How do I restore the master database?” Over time you will find items moving from one set in your Venn diagram to another. What you will also find is that your ability to ask questions, especially the right questions, will improve with time. And it is through those questions that you can make great strides in helping to define requirements.

Scope Creep

Scope creep happens to projects when changes are allowed to go unchecked. Those changes could be the result of new requirements, new desired features or functionality, or if the focus of the project shifts over time. In basic terms, scope creep is the result of what happens when you let change (or unknowns) control your actions. It also happens when people want things that are not necessarily needed. You might be surprised that people cannot distinguish very well between those things that are called “needs” versus those that are “wants”. (I am not surprised but then again I find myself explaining this concept to my five year old son almost daily).

There is always going to be a difference between those things that are, and are not, important. There is also a difference between an enhancement and a requirement. You cannot allow the scope of a project to change without recognizing that that most likely your deliverable dates are going change as well. You cannot expect the same number of people to increase their production to meet your new requirements. If your scope changes or shifts then you will probably need to either get more resources or to change your deliverable date.

When you start to sense that your project is suffering from scope creep go back and review those requirements. Start asking all the same questions you asked before. Will that make the process longer? Absolutely. But do you want a quality product to be the result of your work, or would you rather just slap something together in production and hope it stays stable long enough for you to fix things the second time around?

Be Specific

I am often criticized for making people be very specific when they are requesting something from me or my team. I cannot stand making assumptions about what people are asking for, especially when their questions make no sense. I was once told to “change the size of the data page for the database and let me know when it is done.” How would you respond to such a request? I responded by saying it was not possible and then asked several follow-up questions in order to understand more about what the developers requirements were.

Of course the manager demanded to know why I was not doing what I was told to do, and asked why I always needed to be so difficult. Look, if asking people to be specific, and asking them for requirements means I am difficult then I can live with that. If you don’t know what you need, or what you require, and also do not understand the technology well enough then you may want to indulge a few questions in order for me to help you. Or you can act like my five year old son does every time I explain the difference between his “wanting” to play the xBox from his “needing” to play.

Right before the PASS Summit this year this cartoon from Dilbert was printed:

Everyone I know at PASS that read the strip that day thought it to be funny and just about dead-on in how a DBA is perceived. Sometimes we get asked to deploy solutions that we know are in conflict with policies, or we know will be an audit risk. When we start asking questions we are always perceived as being a roadblock, much as you see in the cartoon above.

We want the same end result that everyone else wants; a stable production environment that allows our business to succeed. And to help everyone get there, we should all start doing a better job of answering a very simple question: “What are your requirements?”