Why has it become so challenging for corporate America to establish effective internal communication? Meeting goals and objectives seems increasingly difficult to achieve. A common workplace perception is that others block progressive efforts, either intentionally or through incompetence. Could the technology we designed be pushing us further apart instead of uniting our organizations? Is the specialization of the workplace creating a fragmented environment?

Take a look at current job boards. Jobs are segmented first by industry, then by function, and then again by specific skills; there are thousands of specialized niches. In the agrarian economy of a hundred years ago, the work force was much less segmented. If in the last 10,000 years, we have evolved from two classifications--hunter and gatherer--to thousands, what does the future hold?

Specialization takes a toll on communication. How can we communicate effectively in a hyper-specialized business environment? It has become nearly impossible to stay current on all existing technology and the latest and greatest vendor offerings. So, armed with specialized understanding of a particular niche, IT professionals struggle to engage across organizational boundaries. They strain to garner the funding for projects and tools they know will contribute to the improvement of the business decision cycle. Since they are so immersed in the technology mindset, they can fail to break out and connect effectively with their business partners and their needs.

The communication gap between those with technical solutions and those with funding seems huge. Data management professionals understand the virtue of metadata and master data, yet find it challenging to convey the value to the business decision makers effectively.

Conversely, many corporate leaders outside technology do not have the time or desire to extend their thinking into the details of technology. For data management professionals, this gap can be daunting to close. When taking their case to those critical decision makers, they struggle to avoid diving into the details. Those details, while essential to the project, are poisonous to the successful business case presentation.

Those who can cross the chasm successfully and make their case find victory comes when they step outside of their comfort zone and extend themselves. The IT managers who accomplish this always seem to have their projects funded for the coming year. So, what practices can you employ to ensure you are one of the successful ones?

A good first step for an IT professional involves purging all technical language from your vocabulary momentarily. Put yourself into a new pair of shoes and adopt the perspective of a product manager for your company. In a business decision-maker role, there are generally two resources at their disposal: reports from the financial and operations groups, and managing changes to customer-facing systems. Forget the detailed knowledge of the inner workings of that customer-facing application. Most business pros do not see to that level of detail. Worse yet, they generally view the data warehouse or other large database as a big black box of some dubious value.

They do understand their business processes and the pressure to grow their product line. They develop the business case for the executives to give their project the green light. Of course, they are disappointed when the full budget does not get approved, but they believe the team can shave a few steps and still deploy the product on time. In talking to their project manager, a product manager challenges their project manager to find something to cut from the detailed project plan that will not affect a successful product deployment.

Those are the realities in the business manager’s world. To them it is more important to meet the short-term return on investment (ROI) and move on to the next project. Strategic goals are important, provided they fit within the project budget, but they are typically low priority.

The strategy a data management professional can apply is two-fold. First, leave the details behind; you can always refer to them if asked. Second, break your strategic goals into smaller objectives and try to show a positive ROI in each of a series of short steps. In the case where you cannot show the positive ROI in year one or year two, embed the initial elements within projects that are underway.

Here is an example. A BI manager I know understood the benefit that managing business metadata could bring his organization. He formed a partnership with a manager in IT who had begun to evaluate technical solutions for the IT metadata requirements. The problem the IT manager and the BI manager grappled with involved proving the ROI. To garner added support, they jointly engaged the project management lead and the finance lead for the business served by the BI team. While these two new players understood the goals and objectives of this strategic effort, they could not show the short term ROI.

The pitch the BI and IT managers delivered to the two new participants aimed at elevating the understanding of what benefit the new partners could gain from the metadata effort. In addressing their needs, the original team gained allies for the greater cause. To the project manager, the pitch focused on improved impact analysis through data lineage, addressing her concerns over integration bugs. To the finance manager, the pitch concentrated on improving the transparency, supporting his routine operations, and effectively auditing the technology processes serving Finance.

Having gained an intuitive understanding of metadata management’s value, the finance manager and project manager found an aligned project that would also benefit from the metadata work. The budget and ROI for the related project was large enough to absorb the metadata effort and still maintain the positive ROI. Additionally, the finance manager knew of some unused budget that could be transferred to the project, bolstering the ROI of the expanded project. The final packaged solution included the metadata effort and was engaged successfully.

To some readers this may sound like a deceptive practice, but bundling is routinely practiced by managers interested in launching business initiatives. When looking at many project plans and programs, often there are line-items and activities that have a negative ROI. However, if these line-items and activities are included with the rest of the project deliverables, they add to the positive ROI. This is the embodiment of the adage, “The whole is more than the sum of the parts.”

While the example cited illustrates what it takes for the data management professional to adapt and grow, the same can be accomplished by the business professional. Stepping out of the daily concerns, reports, and decisions, you can begin to look at the problem with a new perspective.

The strategy for the person in the business role begins with a series of questions. First they need to ask, once my customer-facing business processes are complete, where does my information go? What happens to it? Who sees it, and who uses it, and to what purposes?

Next, question the reports you rely so heavily upon for decision support. After all, you are staking your professional reputation on them. Where does the data come from? What decisions are embedded in the technical processing of that data? Who can access and change the data? What problems do the BI and data management teams face?

Getting the answers to these questions is the first step towards owning your business decision cycle. You do not need to become an expert in data modeling, metadata management, or data integration. You do need to learn to understand and value the contribution they make to your business decisions.

Here is another example to illustrate the point. In the course of introducing a new product, the product manager of a large firm directed the operations team to begin entering a new value into an existing field on the customer service representative’s screen. This enabled the operations management team to sort the pending sales and find this new product more quickly in the operations system. The best part of this process change was that no technical changes were required. It was basically free, and so the product manager felt quite proud.

However, toward the end of the month, the situation started to go awry. As the new values accumulated in the system, they were passed to the data warehouse, and then on to the BI applications serving Operations, Finance, and Risk. Problems started cropping up system-wide. Reports that many managers relied upon began to be unbalanced and contained erroneous data. Results did not make sense based on historical comparisons. In some reports a new column appeared with the heading “Undefined.”

Unlike the other example of a success story, this one exemplifies a very common failure, one that turned out to be expensive to fix. This company implemented technical safeguards to prevent future occurrences of this mistaken use of a technical capability, but the big lesson learned here went to the product manager and executives. The product manager discovered his inadequate understanding of interdependencies. The executive team discovered system development lifecycle processes could be bypassed. They all learned the value of learning how the business processes executed by humans interact with business processes embedded in technology.

By improving the knowledge of the complete business decision cycle, the business management team learned to fully appreciate the requests coming from the data management and business intelligence team. This increased the value placed on master data, reference data, and practices supporting data integration.

A hidden benefit of examining the business processes embedded within the coding and business rules of your technology is the opportunity to identify wasteful or obsolete processes. You get the chance to improve efficiency by discovering processes that have over time been long forgotten and orphaned. In pruning the business process, employees tending that old application can now be reassigned to direct their effort from a low value task to a high ROI task.

To close the communication gap, stepping outside your comprehension zone is an essential first step. It requires leaving preconceptions behind and becoming more open to foreign ideas. Take this challenge: when attending the next professional conference. If you are a technical professional, audit the sessions focusing on business processes and the human dynamic. If you are a business professional, choose a few beginning and intermediate data management subjects. With this growing knowledge, you will begin to bridge the great business / technical communication divide.

About The Author

Tom Jesionowski possesses over 30 years experience in a wide range of industries including banking, wireless telecommunications, electronics, and nuclear power production. That experience has presented him with a pragmatic view into how people, processes, and technology can work in concert. He has recently begun to consult privately as Prime Data Consulting LLC based near Seattle. Tom's blog can be found at http://primedataconsulting.com/blogPDC/, and he may be reached by email at tom@primedataconsulting.com.