How Can we Disrupt? We Can’t Even Communicate!
If you want to communicate better:
- Communication starts with transparency between business and IT.
- Ensure a common jargon that BOTH sides of the discussion understand to effectively communicate complex ideas.
- Commit a subject matter expert full time to communicate with throughout the project.
Communication is the Key
Business and IT Collaboration is fundamental to disrupting the marketplace. The biggest challenge to collaboration is communication, or more correctly, lack of communication. Improving your communication and therefore your collaboration can be achieved by education and transparency, developing a common jargon, and increasing the amount of business/IT interaction.
Education and Transparency
Take a walk through any business and you often will hear a version of “They just doesn’t understand!” or “Why don’t they just give me…” You can be sure there is no collaboration going on in this environment. If there is no collaboration, there is no disruption. These are symptomatic of environments where there is no transparency and very little understanding of what the other party needs to adequately do their job.
A Scenario:
A developer is tasked with providing a widget ordering page for the WidgetMaster 3000. Meetings are had, requirements are gathered. The developer returns to his Lego covered workstation not to be heard from again for another 4 weeks. He returns with a website to order the widgets. He is proud of the interface, but the business cannot see a way to select the radius for the round widgets. Where did he put that setting? Why isn’t there a setting for radius?
Your manager is frustrated because he was pressured to get the ordering system done by next week. How is he going to keep his 
job if these things keep happening? He pours over the documentation and finds safety in the statement something like “The user can search for widgets by dimension.” Clearly they (the developer) cannot deny that radius is a dimension.
Your developer is frustrated because he had no idea that there were even round widgets. Now he has to kludge something together… 
maybe if he makes the width equal the radius if the widget type is “Round”. There is no way to make this fix without making the code a pile of spaghetti. Clearly, that is what the business wants.
Both sides of this scenario are frustrated, and they feel like the other side is to blame.
It was the developer’s fault that the business understand what he needed and what he was working on.
- There was a failure to communicate.
- As the expert, the owness was on the developer to educate the business about what he was building while he was building it.
- The developer, and the IT staff in whole need to educate the business on what exactly the process is for implementing the technology.
- The business may not want to see the sausage being made, but they do need to understand that there is sausage being made and what steps are involved to make it.
It was the businesses fault that the developer didn’t understand.
- There was a failure to communicate.
- As the subject matter experts, the owness was on the business to educate the developer as he was developing.
- As the business, it is in their best interest to be completely involved with the project WHILE it is being worked on.
- The business doesn’t need to know how things are being done, but they do need to be plugged into what is going on so that they can correct and educate as needed.
As long as there is an opaque wall between business and IT, communication (therefore collaboration) and disruption are unlikely. Both sides need to make an effort to ensure that there is transparency throughout the entirety of a project.
Developing a Common Jargon
In every profession there is a common language that is used to clearly describe to others in the profession the message you are trying to convey. By its very nature, this jargon becomes so common that the people using it do not even have to translate the meaning, they just “know” what the jargon means and implies. It is this jargon that unifies the members of the profession. It is very clear, concise and often an abbreviation for an entire paragraph of description. Unfortunately, this jargon is also the thing that excludes people from a discussion. Business specific jargon can be a maze of terms that on the surface appear like 2 entirely different things and are actually the same or things that appear the similar and are really quite different.
An Example of Jargon Exclusion
There was a developer that worked for a company that worked for a company that dealt with medical claims forms processing. He spoke to several people at the company about what their part was in the process. He learned they handled 2 different types of forms, the 837 and the 5010. He set off to write some code to ingest the data, he found a library built specifically to handle 837s and another library to handle 5010 forms as well. It wasn’t until after he delivered the importers that he learned that the 2 forms were in fact the same form. The 837 is the EDI standard for transmitting information as defined in the 5010. He had written double the code and had totally missed the mark. He didn’t know the business jargon, and they didn’t know he didn’t know.
While jargon within the domain can be very helpful to exactly convey your meaning, be sure all in the conversation have been properly educated what the jargon means.
Business and IT Need to Work Closely
It should come as no surprise at this point that if the 2 previous steps were met, this point would be obvious. Unfortunately, often times when a business case is developed for an IT group to work on a project, there is no calculation of the cost of the business representative’s time to be a full fledged part of the project. As a result, the subject matter expert takes on the additional role of providing information to the business. This is almost always folly.
When an IT person is at a point where they have a question, they are faced with 4 choices:
- Talk to the business person to get the answer.
- If the person is available, the question is answered, implementation continues
- If the person is not available then they must choose from the below
- Stop working on this project/feature.
- Better to not do something than to do it wrong.
- Make their best guess and continue.
- Better to have something that is a guess than to do nothing.
- A deadline is a deadline
- Make a system that can handle either option later when you find it out.
- Build something that will work no matter what.
- In other words, over engineer the solution.
While it is true that business resources still have to do the day to day business, there are very few good outcomes if the business does not work closely with the IT group during the planning, and execution phases of a project.
Collaboration and Disruption Go hand in Hand
If you plan to disrupt, you must collaborate. To effectively collaborate, you must communicate. For better communication there must be transparency between the business and the IT department, there must be a common jargon to base your communication from, and you must have a subject matter expert completely committed to the project.
Companies cannot disrupt if they cannot collaborate. The essential ingredient to collaboration is communication~Tal McMahon
