The great communications divide

The saying goes that talk is cheap. But when it comes to managing an IT project, the wrong talk can mean considerable costs and delays.

The IT world is rife with acronyms and terminologies that are often meaningless to the non-tech audience. I recently came across a case study in which the developer injected terms like LOINC (no definition provided, but for those not in the know, it’s Logical Observation Identifiers Names and Codes so Google says). That was far from being the only head scratcher.

For their part, development teams can be stymied by broad sweeping business terms that have no clear definition or context, such as “customer” or “sale”, which leave too much room for interpretation on the part of IT when it comes to data sets. For example, is a sale defined by an order confirmation, order placement, invoice date or receipt of funds?

When IT and business units played in their own sandboxes, that was all well and good. But times have changed and the odds of miscommunication are increasing exponentially.

Phil Simon, industry follower, speaker and author of numerous books on the issue of communications, including Why New Systems Fail and Message Not Received, stresses that miscommunication has become a by-product of changing roles people are playing in the industry. “Go back 10 years and IT people tended to be separated from the business. Roles were more clearly defined. Things are a lot murkier now. Now IT is sitting with HR, finance and other lines of business. Things aren’t as clear cut. A lot of things have changed to make things better in some ways, but worse in others.”

Collaboration tools, messaging and email have all become essential communications tools – and rightfully so. Yet the over-abundance of written word dialogues can open the doors to even more errors in interpretation, especially when it comes to large-scale development projects.

At some point, the written word can work against you as much as for you. Simon offers some good advice in what he calls the three-email rule: “Using email to manage projects is insane. After three you need to talk – and not through a collaboration tool.”

Another Simon rule is to dispense with acronyms and jargon, unless you’re prepared to explain or define them consistently in a way that allows everyone to understand what they mean. “Not doing that is irresponsible,” he said. “Why wouldn’t you want to do everything you could to maximize the probability of success on a project? If you minimize jargon over email that will greatly increase the odds you will be successful. It’s bad for business to assume everyone knows what you’re talking about. If you don’t understand things at a strategic or project level, you don’t see what good can come of it.”

Data terms in particular can be problematic, he added. “Not all project management is created the same. A bank or healthcare organization concerned about security risk would use a different approach to someone launching an Angry Birds update. In the case of the former, if you’re not clear on the data terms, really bad things can happen.”

Despite all the collaboration tools and technology advancements, project failure rates haven’t shifted in two decades, according to Jason Benfield, director of product marketing for Blueprint, a provider of requirements definition and management (RDM) software. “If you look at The Standish Group’s surveys over the last 15 years on why projects fail, the percentage has always been around 60 to 70 percent,” he said. “Either they went way over budget or never got to market.”

The Standish Group’s 2014 Chaos Report offers up some compelling data on project failures:

• The US spends more than $250 billion each year on IT application development of approximately 175,000 projects
• The average cost of a development project for a large company is $2,322,000
• 1% of projects will be cancelled before they ever get completed
• 7% of projects will cost 189% of their original estimates
• Lost opportunity costs could easily be in the trillions of dollars

It doesn’t seem to matter which methodology you use. Whether it’s Waterfall (a sequential design process in which all requirements are established prior to development and launch), or Agile (an adaptive process that evolves through collaboration between teams), the language around requirements are problematic, Benfield said. “Whatever the choice, the same language barrier exists. There was a great study from PMI [Project Management Institute] last year that indicated requirements were essentially the major reason why projects fail. Even though organizations are transitioning to Agile, they’re still finding that core requirements remain a big problem.”

That’s because requirements have always been – and will continue to be – very difficult for people to write and to consume. “One fundamental reason for that is that you either have someone writing requirements from the business side who is not very technical so they don’t do any good for the development team,” Benfield explained. “Conversely, the developers can get too verbose and turn requirements into a giant phone book that nobody on the business side wants to read. Without business/IT alignment, there’s a lot of misdirection when executing requirements, so you end up with last minute change requests that will delay releases.”

Visualization may be the most effective way to bridge the divide that continues to plague project management processes. The Blueprint platform, for example, was designed to transition people away from text-based requirements to a visual, contextual approach to requirements. Modelling can be in the form of mockups, wireframes, system diagrams or business process flowcharts that indicate how something will be used and/or will interact. The idea is that business and IT can take those pictures and extract requirements for delivery to the development team.

What visualization offers that words on a page cannot convey is a clear context, Benfield argued. “The English language is very complex so if you read anything without a lot of context, a sentence or phrase can be very confusing.”

Blueprint recently produced a series of videos that puts the importance of visualization into perspective. In one video, Benfield elaborates on the need to use models to align business with IT in order to avoid some of the complexities of the English language. In another, Benfield demonstrates a process flow based on user stories that walks through the initial decisions to go skiing, the equipment needed, proper attire for staying warm and equipment rentals. On the right side of the screen, the action that goes with each step in the process is shown. The point of the exercise is that the visual side of the picture is all about water skiing. “When you just read the user stories, you automatically think snow-skiing. Once you see the visual, the context is apparent,” Benfield explained.

An even simpler analogy is LEGO building blocks, he added. “If you buy a child a set of LEGO blocks there are no words in the instructions. Only pictures. Because of that a five-year-old can put it together. If you gave them in text, even a 12-year-old would have difficulty building it.”

So can visualization make a dent in project failure numbers, where other attempts have failed over the years? You could say, that remains to be seen…