The theory is that there are no stupid questions. Okay, this is not quite true – but more on this later. First, a story.

I had a client a few years ago who was nervous about an interview I was about to do with a difficult business user in the early stages of a project. He asked for my list of questions for the interview in advance. I gave him my list:

 “How does your department contribute to the success of the organization?”

“What works well and what areas/products/projects could be improved?”

“What do you need this [new computer system] to do to help you achieve your mandate?”

“What are the risks that I need to consider as we plan for and implement this [new computer system]?”

My client seemed unimpressed with my list and unsure that we would actually need the 2 hours we had booked for this conversation.  Of course (because this is my blog entry, not yours), we had a great meeting, garnered the support of the previously difficult business user, and after the meeting, my client told me that he couldn’t believe that we had such a great meeting when I went in with a simple list of 4 questions.

As you can imagine, I actually asked many more questions than just the 4 listed, but all as part of a dialogue.  The four questions keep the focus on key meeting outcomes and serve to get the conversation started.

Whether you are collecting business requirements, learning about a vendor proposal, or managing a staff member, asking open-ended, neutral questions is the key. And there’s nothing wrong with asking really basic questions (“why do you do that?”) that drive the discussion back to the first principles – i.e., what are we trying to accomplish with this project/department/product  - that can get lost in the urgency of day-to-day operations.

And as for the no stupid questions theory, rest assured that there are entirely stupid questions – questions that demonstrate that you haven’t been listening, or don’t care about the answer you just got, or trick questions that get asked because somebody has a hidden agenda.  But those are for a different blog entry.

Christy DeMont

While we provide solutions that drive success in business, IT doesn’t directly make money for the company – so while what we do is business critical, we are still primarily in the business of providing service to other functions.

So what happens when something goes wrong?

There are two possible responses to a customer service problem.  The first response is, “This is unacceptable. This must be resolved immediately”.  The second response is, “It’s a problem, but it’s not a big deal. We can figure out a work-around until it gets fixed”.

Now here’s where the light bulb goes on:  if you are providing service to a customer, and a problem comes up, you get to pick your response first.  The 100% always true no fail guarantee is that whichever response you pick, your customer will pick the other one.

The cool thing is that it doesn’t matter if it’s a broken cellphone or a million dollar piece of software - it still works this way. (It also works the same way if your restaurant meal isn’t satisfactory or you are trying to return something to a store or somebody messed up your tee time – try it and see!)

And when people in your organization see how seriously you take the fact that their blackberry isn’t working properly, they will understand that you also take their big problems seriously, and the next time you have a significant issue you will have their support. It’s amazing how much support you can get from your business colleagues by sending somebody out to the store to spend a couple of hundred dollars on a phone.

Christy DeMont

There are good ways and bad ways to make decisions around technological change. 

Bad technology decisions get made when they are tied to somebody’s pet project, or as a kneejerk reaction to some business or technology failure, or when an IT executive can’t articulate the business value of an investment, to name a few.

So here’s a thought – let’s align IT business plans with organization business plans.  So every project that the IT team wants to do is examined and success defined in the context of which tactics and strategies it enables.

What happens when we do this?

1. Clear business sponsorship for IT projects. If the operations manager understands that to achieve his goals (and get his bonus) he needs a technology solution implemented, he will fight for it and support it.
2. Clear business direction for the IT team.  The solution has a clearly defined pressing set of outcomes needed, the team knows why this is important, and can make day-to-day decisions with an appropriate context.
3. Clear implications when business goals and priorities change.  Cost cutting exercises show direct implications for the business (if I stop work on this project, we won’t be able to deliver this business goal).
4. Clear communications about projects and activities in language that all business leaders can understand.
5. Clear evidence of contribution of the IT team to the overall organization results – so the CIO gets her bonus, and team members are appropriately rewarded for their contributions.

Christy DeMont

If it takes 2 weeks to get a new computer or phone, if the computer you have has to be shut down and restarted 3 times a day, if the systems don’t produce the reports you need to make business decisions, you are not getting everything you should be getting out of your technology investment.

It’s time to start asking questions.

Christy DeMont