Learning to Ask IT the Right Questions

Company executives often seem to purposefully keep IT at a distance.

Amritpal Singh Fulltime Graduate Student MBA Program Barney School of Business University Of Hartford, USA

At a time when businesses rely on IT to manage intellectual property, along with financial systems and operations, that mentality makes no sense, considering the potential value, as well as the risks that are involved.

Granted, IT may seem like a black art with its acronyms, specialized, yet non-standard, verbiage, and technology that is sometimes out of date as soon as it's out of the package. But there are some simple points to keep in mind that can help executives when they're judging the value of IT investments.

Centuries ago, Socrates put forth what is known today as the ''Socratic Method'', and it's useful in the IT context. Essentially, Socrates asked his pupils questions designed to help them arrive at the answers. Thus, he didn't necessarily need to know the answer to everything, but he did need to know the questions to ask and the underlying logic that created them.

This method is very applicable to today's business and IT investments.
Senior executives do not necessarily need to understand the minutiae of IT. However, they need to ask some simple questions and the answers need to be carefully reviewed.

For example, consider the following questions when reviewing proposals from project teams:

• How does this proposed project help the organization achieve its objectives? Why should we invest in this? An IT project should either add value or reduce risk.
• Is the project's objective measurable? If it isn't, how will you know that the project is done and/or successful?
• Who was involved with creating the proposed solution? Did the project team involve the right people to truly create a solution?
• Is this project dependent on any other projects? What risks are associated with this dependency and how will the team manage them? Sometimes a hidden dependency can doom a project before it has even started.
• Did finance review the money side? Do they approve of the project?
• What are the risks associated with this project? Any project carries with it some degree of risk. Did the project team formally consider all of the risks and come up with mitigating controls in alignment with the organization's risk appetite?
• What if this project fails? This key question should be part of the above-mentioned risk management plan. Should this project fail, will the firm be none-the-worse-for-wear, worse off, better off, or some combination thereof?
• Who reviewed the technical aspects of the proposal for issues like standardization, capacity and database design? Did they approve? The goal is to avoid surprises, such as finding out that a project in one area requires resources that are constrained in another.
• Who reviewed the process aspects? Did they approve? For a successful outcome, any project must assess the impacts not just on technology, but also on people and processes. Can the organization support any changes?
• Who reviewed the human, or HR, aspects? Did they approve? Again, successful projects rely on people, processes and technology. Can the people support the project? Do they have the right skills? Will there be a political impediment?
• Who reviewed the project plan? At the heart of all this is sound project management. A formal plan should exist following a methodology approved by the organization.
• Who reviewed the IT security aspects? All too often, security is brought in at the end of the project. IT security should be involved from the start to identify any risks that need to be addressed.
• Did the sponsor and stakeholders formally approve the project? For the sake of accountability, require that the project sponsor and stakeholders sign off on the project. This is to ensure that the objectives, requirements, risks and expenses are clearly understood. This is done to avoid the useless blame-game that happens when problems arise. It also will send a clear message that proper planning, communication and demonstrable results are mandatory.
• Now weigh the answers to my above questions.
  

First off, if the presenter can't answer the above questions or an unsatisfactory answer comes back, do not approve the project. Make them get the answers and come back. It will not take too many repetitions before the word gets around that management is serious about understanding projects.

And make sure you read between the lines when you're being given the answers. Notice how the message is communicated, body language, etc. If they know the answers and believe in the project, their confidence will show.

Don't forget that the questions aren't about bits and bytes or other IT-centric verbiage. If the respondents delve into techno-babble, simply tell them to restate their answer in business terms.

The purpose of this article is not to downplay the need for tech-savvy or tech-aware executives to help set strategic direction. But keep in mind this simple concept -- as a person moves up the corporate ladder, the job requirements shift from knowing the technical details to knowing the right questions to ask. Each organization is different so the key questions will differ.

However, the desire is the same -- to ensure that all the aspects of a proposed project have been thought out, and that you have the information you need to make a strong business decision.