David A. Zimmer, PMP
Chief of Staff
American Eagle Group
In a recent article by a colleague titled “Will the REAL Definition of Unified Communications Please Stand Up,” Blair Pleasant offered a definition of unified communications. Overall, I felt the definition provided insight and was comprehensive from a technical perspective. She included the many “moving” parts, the technical components, needed to support a unified communications (UC) infrastructure.
Ms. Pleasant’s real premise of the article was to provide that one definition we can use to effectively describe UC – the “elevator speech” of UC. This is a goal another colleague Art Rosenberg and I have attempted many times over the past decade since we coined the term “unified communications.” No matter what we developed, I always felt short-changed, incomplete, not totally satisfied.
After reading Ms. Pleasant’s article and talking with Art, I came upon the root issue to this lacking definition. We typically attempt to define UC from one perspective which leaves the other perspectives dangling. UC is a rapidly moving, and yet frustratingly slow, whirlwind of needs, wants and whims. A need to one person is simply a whim to another. So, to pin a single definition on UC is fruitless. As soon as we are satisfied with the definition, it is outmoded, just as a PC purchased yesterday is obsolete.
A Departure From UC
Back in 2002 or 2003, I took a departure from the UC market to provide training and consulting to companies in the area of project management and IT service management. Over the past several years, I have trained thousands in industry-standard project management methodologies and proper MS Project use. During these seminars, I refered to unified communications. I’ve learned, based upon the person’s job description, their definition and understanding differs.
Rather than a single definition, I believe there is and always will be multiple definitions. The definitions result from different perspectives. I’ve captured these perspectives in what I call, the UC Cube©. It is a specialized version of the IT Cube© specific for UC although it uses the same perspectives.
What is UC Cube?
Over the years, I have been involved in many IT related projects. During that time, I have observed many perspectives to the project. Some felt the project was a raging success while others, looking at the same information, considered it a flaming failure. Why? I realized they were viewing the situation from different angles.
Imagine a cube – a six sided, 3D object. In the center of cube is the item of scrutiny. Depending upon which panel I am looking through to see the item, I see another aspect, a distinct surface resulting in “seeing the same thing, but differently.”
Let’s tie this to UC.
Any IT project, and UC eventually boils to technology implementation, has six different perspectives. I make some generalities to simplify the concept. There always will be grey areas and bleed-overs to other panels, but the following descriptions will help us understand our conundrum.
Panel 1: The Technician
The technician implements, maintains and upgrades the infrastructure that supports the features and functions of the UC system. He may have insight into only one portion of the overall system. For example, he may be the MS Exchange or Domino Server guru. He may not understand or be concerned with telecom stuff.
Regardless of how narrow or expansive his technical skill set, he is the one that understands the nuts-and-bolts. He must make the adjustments necessary to keep the system alive.
His perspective is technical. His questions and concept of UC is technical.
“What components must I implement and maintain to produce UC?”
“What widgets comprise a UC infrastructure?”
“Should I support VoIP or TDM?”
“What expertise do I need or certification should I possess?”
“What training best serves this area?”
And so on.
Panel 2: The IT or Technology Management
The IT or Technology manager, while concerned with the technology and its implementation, concentrates on uptime, stability, business support, evolution to meet future needs, etc. She reads different reports and magazines than the technician. Her concern is less day-to-day operations and more focused on providing the features/functions with appropriate availability to support the organization.
The IT manager’s perspective will be technical but with a “business” flavor added.
“Which set of technology meets the greatest number of needs expressed with the greatest uptime and lowest cost?”
“Can I prove ROI, TCO, ABC and XYZ the business slings at me?”
“At the end of the day, am I supporting their needs, wants and whims?”
“What metrics best prove I’m meeting my SLAs?”
“How do I really know the users’ needs?”
“Are the business initiatives being met by this latest technology implementation?”
Panel 3: Business Management and Executives
The business management focuses on company profitability, costs and competitiveness. If tin cans and string support the communication need, so be it. If it takes the latest advances and technology, that’s fine as long as it keeps us profitable and competitive. The goal is to manage the business, not the technology to support the company. The business defines the business requirements for profitability and competitiveness while the technology management translates those requirements into working technology.
The business’ view of UC revolves around reaction to market trends, business directions, customer responsiveness and so forth. If technology enables mobility, agility and profitability, they’re for it. Does the UC system integrate with our business processes and support greater productivity so we can do more with less?
While it is the IT manager’s responsibility to prove proper ROI and TCO, the business management factors those values into the equation for the cost of IT support. In other words, if the current system supports the business but doesn’t line-up with an industry definition of unified communication, who cares? If a UC system is implemented but doesn’t support the business, UC is no good. Simple.
The business perspective, therefore, looks at UC’s impact on the business itself and determines which “features and functions” are necessary. If IM does the job, it’s in. If UM doesn’t support profitability, it’s out. Yet, if the workers can get to their email, voicemail, fax and other communications just fine, they have “unified communications.”
Panel 4: The User
The rubber meets the road with the user. The user determines which aspects of UC he uses. Some might use IM. Others might use text/picture messaging from their mobile phone. One set wants iPhone® while the rest want Blackberries®. For business purposes, email and voicemail are required options, but their use might vary. Should we throw in calendaring functions and contact lists? Can they only contain business associates or will they contain family and friends? Does it support “presence” for all contexts so the user knows which device or medium to use?
Some users have a clearly defined boundary between work and personal life while others have no life outside of work – everyone is a potential customer. Some users are highly mobile requiring different types of security and equipment definitions while others might share devices because of their duties such as manufacturing shop floors and support desks.
Since each job varies drastically from one company to another, from one industry to another and from one country to another, a single definition will not suffice. Here’s the key: each user will define UC for himself or herself based upon his or her specific needs and job demands. The person across the aisle may want something completely different. Consequently, the IT staff must support a smorgasbord of features and functions, within limits of course, to cover the variety of definitions.
Which definition prevails? The business manager’s? The IT manager’s? The technician’s? The user’s? All will!
Here’s another aspect of a user, just to muddy the waters. Generational issues. Yup, this is one place age really does matter. Each generation has different ways of working based upon the technology available when they were young.
Not to give away my age, but I much prefer separated technology where my voicemail is voicemail and my email is email. Although I carry a Blackberry fully loaded with pictures, soccer schedules, contact information, email/spam-mail, I don’t do texting. I don’t like IM – too invasive. I don’t want my voicemail comingled with my email and overflowing spam. And my “find me/follow me” is fixed forwarding of my office phone to my mobile number. I don’t need more.
And I really despise presence. Why? Because, frankly, I don’t always want to be available. Worse, just because my mobile phone is on and the presence indicator says I’m available via that method, I’m not. I’ve left it behind because I needed a break. But for many, presence is the coup de grais of UC. Without it, UC isn’t UC!
While I have this older view of the world, my younger counterparts (and off-spring) are suffering carpel tunnel syndrome of the thumbs from texting/IM’ing/video-gaming, and more. They have a different concept of work and play from me. Their communications needs differ.
I have a problem with “communicating” with robots and systems that simulate humans helping me with my tech support while the younger folks like it better. I don’t want to speak to a machine trying to act like a human. I’m not a fan of tech support “live chat” while other love it – too slow and I know I am not the only customer of the tech, therefore, I have to repeat myself too many times and get inaccurate answers.
Therefore, the user defines UC to meet his or her need. It cannot be dictated by the industry.
Panel 5: Analysts and Pundits
The analysts and pundits will have a completely different definition for UC than everyone else – by definition. Our job is to determine the market size, advise our clients what’s best, apprise them of the future after we predict it, and convince them our guesses are just around the corner. Therefore, our definition will be a combination of technical specifications, market forecasts, customer requests and users demands (as determined by surveys). I’m not trying to be harsh, simply reality based.
We will ask,
“What are you current pain points?”
“What problems are you trying to fix?”
“What solutions do you think best fit your situation?”
“How many users do you support?”
“What purchases are forecast for next year, and the year after that, and five years out?”
“What functions do you foresee as important today that you don’t have?”
“What are your predictions for next year?”
We take the information and see how it matches current products and services, then illustrate the current gaps and the market potential. Of course, we have to define the problem we are solving in order to come to a solution. The solution, therefore, evolves into our definition with additional future-proofing. While this is a bit “tongue-in-cheek” of our services, our vision of UC differs from all the other groups, by necessity.
As analysts, we have to stand squarely in the past, the present and the future. The technology must support all three timeframes, the features must meet all needs expressed or at least in a prioritize order of needs, and so forth. Our view and definition of UC can be biased based upon the data collected, the reports read, the information mined and more. The good news is, we can be just as right as any other panel.
Panel 6: The Vendors
The vendors are in business to meet the needs of the customers. Their goal is to understand the definition sufficiently to produce the product or service supporting the definition. Of course, no one vendor can meet the entire definition, therefore, they express how their products/services are UC.
I once saw a vendor claim they had “unified messaging” because they could receive faxes on a PC. It did not integrate with a mailbox, email, voicemail or any other product, but that was their definition of unified messaging – PC fax.
The vendor’s definition of UC will be biased toward their product or service. In many cases, they will fit a square peg in a square hole, but sometimes, it will be more cylindrical than square.
They will be asking questions such as,
“How does our product or service fit this concept of UC?”
“Do we have some aspects that will work so we can make such a claim?”
“Can we state we are UC-compliant?”
And so forth.
Conclusion
Defining UC with a single, industry acceptable definition is impossible. No matter how inclusive, it will certainly exclude some aspect. We must define it from multiple perspectives. We must realize also UC is constantly moving and shifting. There are many moving parts which are evolving at various rates and directions. Users’ needs, wants and whims are never static and change like the wind. Market factors, economic conditions and business climates impact UC quarterly.
The six perspectives give us a clue as to the true complexity of UC. The complexity results from the various viewpoints, more complex than the technical aspect. Serving each angle will challenge us for years to come.
What Do You Think?
Do you think it is possible to have a single definition? Do you think I am accurate in articulating six perspectives? Does the concept of a cube help focus this amorphous collection of needs, wants, whims and technology into something tangible? Send me your thoughts. Either leave a comment to this blog posting or send me an email at info@ameagle.com.
To learn more about my kick-butt Project Management 5-day boot camp or excellently rated MS Project seminars, shoot me an email or call +1/215-491-2544. Thousands have reaped the benefits of more project success from this valuable training.
UC Cube is copyrighted by the Unified-View. IT Cube is copyrighted by American Eagle Group. All rights reserved. Use of term permitted with credit citation to respective copyright holders.
Copyright (C) 2008 Unified-View, All Rights Reserved.
Posts
