Say what?

Say what?

When IT and business deal with each other, expectations are set early in the process by how each side communicates its needs and how well both sides clarify their agreements. So why is it that, a month later, the business is unhappy and IT is confused?

When IT and business deal with each other, expectations are set early in the process by how each side communicates its needs and how well both sides clarify their agreements. Conversations between IT and the business often seem straightforward enough, with both parties leaving the room nodding in agreement. So why is it that, a month later, the business is unhappy and IT is confused? It’s possible, even probable, that your business counterparts heard something different that you thought you were saying. Is that IT’s fault, you ask? Maybe, maybe not. But it really doesn’t matter. Miscommunication is not resolved by deciding who’s at fault. I’d like to present a somewhat exaggerated version of common IT-to-business miscommunications and offer some suggestions on how to bridge the communication gap.

We need to analyse the situation…

When IT says: We want to do a thorough analysis of the current process and come up with recommendations for the future state. We are looking to provide you with better tools to support your business needs.

The business hears: IT wants to put in some new “cool” technology that it thinks will solve all our business problems. Sure it will!

What needs to be done: Too often, IT approaches a project with a technical solution already in mind and wants to do analysis only to get the information it needs to gain management approval. The business worries that IT thinks it knows more about the needs of the business than the business does. This can lead to business taking a fatalistic view that, if IT’s solution doesn’t work, business can just keep using the old system.

To overcome this mindset, the business and IT need to work together to document the current or “as is” state. This effort should be time-boxed to provide just enough information to determine where the work is starting and define any metrics currently used to measure performance. From there, the business needs to determine what the future or “to be” state will look like and how that aligns with the business strategy. As a partner in the effort, IT will use this to-be analysis to define the needed capabilities and begin to translate those into programs and projects that IT will deliver. At the same time, the business will define process and organisational projects that need to be completed. Together they will create a joint programme plan that sequences the various projects.

We need the business community’s help…

When IT says: We will need your subject matter experts (SMEs) to participate in the discovery and analysis phases of the work.

The business hears: IT is going to create a bunch of flow charts that we don’t understand. We will just tell them what we need and ignore the charts.

What needs to be done: A common source of misunderstanding between IT and business happens when IT blindly follows its system development life cycle methodology, which requires it to consult with the business SMEs. Meetings are held, but the IT project team either misinterprets the SME input or it doesn’t do a good job of communicating the input back to business decision makers. It may also bury its findings in complicated diagrams and IT jargon that business decision makers have difficulty understanding.

SMEs need to be assigned and be available to work with IT, and their input needs to be included in the work plan and decision making. Neither side should be just going through the motions. SMEs must communicate, and IT must grasp, the impact of alternatives on the to-be business process. The documentation it produces must be user-friendly.

We want to better align IT and business…

What IT says: We need to work together to understand the business drivers so we can develop our IT plan and enterprise architecture.

What business hears: IT has been talking about putting together an enterprise architecture for years, but this planning just seems to mean attending a lot of meetings and listening to IT spout a lot of technical jargon that we don’t understand. We will assign our “B” players to the project.

What needs to be done: IT needs to talk less and listen more. An enterprise architecture is not just a system and technology architecture; it needs to be married to the business architecture. The business should be doing the majority of the talking at a planning meeting; business leaders should be driving those meetings and be accountable for the outcomes.

Mary Ann Maxwell is group vice-president, executive programmes, Gartner.

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags aligning it with the business

Show Comments