Goldilocks pulled down the covers and climbed into Papa Bear's Great Big Bed. But she quickly jumped down. 'That bed is MUCH too hard!' she said.
Then she tried Mamma Bear's Medium size bed. But it was too soft. So she climbed into Baby Bear's Tiny Little Bed. It was JUST right.
Then she tried Mamma Bear's Medium size bed. But it was too soft.
So she climbed into Baby Bear's Tiny Little Bed. It was JUST right.
Sure, Goldilocks might be guilty of breaking and entering, but to her credit, she appears able to quickly analyze options and make decisions. It's the same in our enterprise technology decision-making: Analyze, research, pilot, but in the end you need to decide in order to move forward.
If you had an opportunity to attend Enterprise Connect at the beginning of this year or regularly read No Jitter, you know that virtually every week you have new communication and collaboration options to consider. Recent new options appeared with the launch of Microsoft Office 365 and the launch of Cisco App HQ along with more details on their Cius tablet device, just to name a few.
Having helped organizations make technology decisions for the past 20 years, I'd like to offer some tips, observations on avoiding pitfalls, and some advice on how you might go about making these decisions.
I believe making a good communication platform decision--one that’s "just right"--comes down to seven key steps:
1. Define and document requirements--by interviewing or surveying actual end users.
2. Define multiple viable options--but prune as early as possible.
3. List Pros/Cons--show your work and base ratings on the documented requirements
4. Provide budgetary costing for each option--"Show me the money"
5. Make a Recommendation--don't be afraid to make a point-in-time decision
6. Pilot--to validate technical interoperability, but more importantly user adoption.
7. Doing something is almost always better than doing nothing. (I know this is technically not a step, but it is so important to remember I added it to the list.)
Features Are Not Requirements
I often write and speak about the need to match a communication solution with defined and documented business requirements. But exactly how do you go about gathering and documenting these business requirements?
First, I believe you must understand that despite what vendors tend to preach, features are not requirements. Repeat after me: "features are not requirements". Simply because product 1's manufacturer decided to offer feature A does not necessarily mean any of my end users will actually use this feature. Only by documenting actual end user requirements will you understand what features are true requirements and what features are simply extraneous bullets on glossy marketing brochures.
Understanding requirements takes time. Pretend I am a vendor sales rep. If I do not have, or do not take, the time to understand the specific requirements of your organization, then I need to lead with my "feature list". I need to convince you that my "417 telephony configuration options" (actual number may vary) are what your users need. Of course, if you have not documented your user requirements, it might seem like having more features reduces the risk of missing a key requirement. However, feature quantity alone does not reduce the likelihood of a gap in specifications or expectations. More features is not inherently better.
Features are not requirements and the only way to know your organization’s specific requirements is to take the time to gather and document them (in writing!).
Gathering Requirements
End user requirements
It is always better to talk directly to the true end users.
Talking to end users takes more time, it can sometimes be inconvenient (when the end users say things we don’t want to hear), but there is no shortcut to gathering actual user requirements.
In many large organizations, there are "proxy" end users who serve a "liaison" role between IT and the actual end users. These user proxies may be called things like "relationship managers" or "business analysts". But, whatever they are called, they are not end users.
If you have lots of users you may choose to do a survey. Surveying users allows you to pinpoint requirement differences across different functional groups or in different geographies. But even if I use a survey, I always like to also interview some key end users.
Ahead of an interview, you should compile a list of questions or topics you want to cover. Interviews have a tendency to take on a life of their own and can often uncover issues or opportunities that would not have been evident through a survey alone. In some organizations, all of the requirements are gathered through interviews.
As part of gathering end user requirements, you should try to prioritize these requirements. There is often no perfect solution which will meet all the requirements of all your end user groups. A prioritized list of requirements allows you to make effective trade-off decisions during your option evaluation.
Project Requirements
If you expect to improve business efficiency, reduce cycle time or meet any other specific objectives, then document these objectives and make sure they are measurable and that you determine and document how, specifically, you plan to measure them. If you are planning to improve something, then you will also need to take a baseline measurement.
To be part of a successful project, you need to define and publish your measurable project objectives at the start of your project, meet the objectives and then demonstrate (vocally!) that you met your objectives. This is especially important for pilot projects. Self-PR (i.e. "tooting your own horn") is often key to moving a pilot into production.
Non-functional requirements
There are certain requirements that no end user is likely to express from a personal point of view, because the requirement originates not from the user's perspective, but from larger enterprise drivers. These are often called non-functional requirements and they often are preventative in nature, dealing for example with protecting the overall organization--things like security or backup and restore capability. In certain industries, legislative requirements such as compliance journaling also fall into this category.
To identify important non-functional requirements you need to speak to the people who oversee security, and for regulated industries, often the legal department.
Evaluating the Options
Papa Bear's bed, Mamma Bear's bed, Baby Bear's bed--like Goldilocks we all have multiple viable choices. And with an increasing number of features available in the "cloud," even deployment location becomes another choice.
For any sufficiently large or complex organization, there is no perfect solution. Any solution, even the best one, will require trade-offs and compromise. If you don’t know what trade-offs you are making, then you have not done enough analysis and you have not looked at enough options.
When you’re facing several viable options, you need to list the relevant pros and cons of each. Once again, this is not a battle over which vendor has the most features. Instead, based on your defined, and documented, end user, project, and non-functional requirements, you need to show how each option aligns with these specific requirements.
And in doing this analysis, understanding the limitations of each option is the most important process--and this can be the most difficult. Vendors seldom create brochures talking about the features they don't support or highlighting the features that are not as strong as a competitor's. You need to find a way to involve people with real world experience when evaluating options, and this can be difficult, especially for some of the newer solutions.
Assessing options that involve multi-vendor integrations especially requires extra work. Most vendors lead you to believe that you can integrate anything with anything else. This is what I call the "Integration Myth". The reality is that many multi-vendor integrations have significant limitations. These limitations may matter to you or they may not. You really need to understand your specific requirements and understand the limitations of these more complex integrations and see if they intersect, in a bad way.
Even in the more straightforward voice mail integrations, new versions of software may cause problems. For example, with Microsoft Exchange 2010 service pack 2, some of the Avaya CS1000-to-unified messaging integrations stopped working.
As another example, Cisco changed both operating systems and database platforms in moving their contact centre software from version 7 to version 8. As such, a customized wall-board display we created for a recent contact centre project will need to be re-architected when their contact centre software is upgraded.
Bottom line: Multi-vendor integrations require more diligence during the evaluation process.
By looking at multiple viable options, when someone says, "great recommendation, but did you look at x?" You will be able to respond, "as a matter of fact we did and we did not recommend it because of a, b, and c".
The Power of Status Quo
Doing nothing is always an option. Unfortunately, many organizations "choose" this option simply from fear of proceeding to make a choice.
In looking at options, I have found it is important and valuable to look at the pros and cons of the "status quo" or "doing nothing" option. Simply doing what we have done is often less expensive (in the short-term) and is always easier than any other option, which requires us to do something. Quite frankly, if the other evaluated options do not provide significant business benefit, then doing "nothing" is a valid leading contender.
In contrast, if the current situation is causing end users a significant amount of "pain," then by analyzing the status quo you have the opportunity to enumerate and quantify the existing problems. In the end, the benefits of a new solution must exceed the current pain over a reasonable period of time.
During an option comparison process, we always include the pros and cons of the status quo. Looking at the status quo allows you to document the "pain points" associated with the current situation and helps determine if there is a business case to make the investment required to adopt a new mode of operation.
This Moment in Time
It is easy to get excited about features that are coming in the future, in version "now + 1". However, this is a trap.
I have found that to be successful, in order to be able to evaluate options and make a choice, you need to force yourself to make a point-in-time decision. You must evaluate the options first and foremost based on the here and now.
You can consider the future product roadmap and the history of the vendor, but ultimately, end users can only use the features in the actual shipping product. Trying to evaluate options as of some future date is an insidious trap because every week and certainly every month, new versions and new capabilities are announced and introduced.
If you get caught up in trying to evaluate future possibilities then you will likely never be able to complete your analysis. You become afflicted with analysis paralysis and because the options do change weekly, you can justify the option of continued analysis--right up until the point where someone else takes over your job because you have delivered nothing.
Show Your Work to Get Full Marks
My ten year old son is very good at math. That being said, he sometimes struggles to "show his work" since to him it is clear what the answer is. However, from the perspective of his teacher, if he doesn't "show his work" he won't get full marks. Writing down the correct answer is not good enough. I have found that communication system recommendations are like this.
For each viable option you need to explicitly detail significant differences between the options you are considering. I often create a Comparison Matrix that looks something like this:
I then might visually summarize relative strengths in various areas using "Harvey Balls" similar to the following:
The categories I use in the above table would vary based on what is most relevant to the specific customer.
Transparency in the option evaluation process is key as it allows others to provide input, and to review and identify assumptions that may be incorrect. Transparency also allows you to show the rationale of your recommended direction.
Showing the pros and cons of several viable options helps you understand and build consensus around the best path forward and also helps you defend and explain the rationale of the recommended solution.
Money is the Root of All Evils and the Basis of All Decisions
The actual biblical quote is "The love of money is the root of all kinds of evil" (1 Timothy 6:10). While I don't want to disagree with the Bible, I do believe that when it comes to evaluating decisions, without at least budgetary prices assigned to the options under consideration, it becomes impossible to make a business decision. So for me, the lack of considering money (costs) when evaluating options leads to an inability to make good decisions (and this is evil). All businesses have some form of financial constraint and even those businesses fortunate enough to have large budgets have a fiduciary responsibility to make sound investments.
With my team, ahead of presenting options, we ensure that the relative costs for each option are known. This does not mean needing to finalize the detailed design or create a final bill of materials. It does mean providing budgetary guidance on the relative purchase, implementation and ongoing costs for each solution under consideration.
Warren Buffet said, "It is better to be approximately right than precisely wrong." When identifying the right direction forward, budgetary pricing is good enough. Once a direction is established and agreed upon, detailed design and detailed pricing can then be obtained. Organizations that get caught up in the minute details too early in the process have a tendency to get bogged down and not move forward.
In many cases, certain costs may be deemed similar across all considered solutions. In this case, the costs do not need to be estimated for the purpose of comparing the options. For instance, for a recent customer, all the considered communication platforms supported both T1 or SIP connectivity to the PSTN. As such, as part of the exercise to determine the best platform selection, we did not need to evaluate or compute different PSTN connectivity models. Once a platform was selected, a further exercise to optimize PSTN connectivity could be undertaken if required.
Remember that in evaluating options we are looking to highlight material differences between the different choices. If hardware, licensing, implementation or maintenance costs for one solution is significantly different between the options being considered, this should be highlighted.
The One That Got Away
My first-year business professor once said that the cost of perfect information may outweigh the value of that information. In evaluating options this general principle applies. You need to identify a reasonable number of possible viable options and then complete a pros/cons analysis of these options in comparison to your defined and documented user requirements.
A startup may introduce a new communication product next week, or an established vendor may surprise you with a radically new product version. Worst-case, you will need to "refresh" your analysis if you believe this new information would materially impact the final selection. Don't let the fact that there might be one option you are not aware of stop you from evaluating the key viable options you do know about.
Pruning
Evaluating the details of each option can be time consuming. Therefore, as you proceed through your analysis, if an option fails to meet a mandatory requirement you can "prune" that option. That is to say, you can note the nonconformance and then not be required to prepare further details for that particular option. Pruning is especially important if you are considering a large number of options.
Discarding options from further consideration can be based on a number of factors:
1. Specific features of a product. For instance, up until recently, one leading desktop IM client did not allow multi-party conversations.
2. Supportability. Some integrated multi-vendor solutions are not supported by both vendors.
3. Platform support. One customer ruled out an option because it did not provide a full-featured Macintosh client. Mobile device support greatly varies between UC solutions and might lead to pruning opportunities.
4. Current deployment statistics. Many customers are unwilling to be the first deployment of a particular solution. (Even if a solution is not the first deployment, I would suggest that as part of evaluating options you compare and contrast the number of successful deployments each solution currently has.)
Because most option analysis engagements I undertake present high-level architectures, clients can save a lot of unnecessary work with budgetary pricing on hardware and software plus implementation, pruning an option early in the evaluation process.
Analysis Paralysis
Some persons are very decisive when it comes to avoiding decisions.
--Brendan Francis
Indecision becomes decision with time.
--Author Unknown
The inability to make a decision has often been passed off as patience.
--Author Unknown
Some organizations find the process of performing a detailed analysis for multiple options overwhelming and so they simply do nothing. But doing nothing is very different from analyzing the pros and cons of the status quo and deciding to keep things the way there are. Choosing the status quo is a well thought out and reasoned decision based on evidence. Doing nothing, because of analysis paralysis, is simply irresponsible.
Analysis then Pilot or Pilot then Analyze?
Some organizations like to pilot technologies as opposed to undertaking the more academic analysis approach I have described. I am a believer in pilots. I think piloting new technologies helps IT to better understand the capabilities and limitations of these technologies. I think pilots can help users understand and experience some of the benefits of new technology and help IT better understand "real world" usage scenarios. After even the most detailed options analysis, I think a pilot can validate the selected direction with empirical evidence. I also think pilots can help validate approaches related to training and can be used to fine-tune strategies to drive optimal user usage and adoption.
I am a believer in pilots; however, whether you pilot then analyze or analyze and then pilot, I do not believe multiple pilots (sometimes referred to as a technology "bake-off") can replace the analysis process I have described in this article.
Alternative Approaches
In a purely random event, such as picking numbers for the lottery, previous outcomes do not impact future outcomes. And yet many lottery fanatics spend a good deal of time analyzing previous numbers, convincing themselves previous numbers are more or less likely to occur. Anyone who has studied the branch of mathematics referred to as combinatorics knows this is not the case.
Some organizations are like these misguided lottery players. They do not have the time, patience or knowledge to go through a methodical decision making approach so they try and take a short cut. Some organizations contend that end-users don't actually know what they need or want. This way they convince themselves that they do not need to take the time to discover and document end user requirements.
Some organizations have not had previous success with analytical reports and so they shun this approach. And sometimes, politics or personal preference trumps any methodical evaluation approach.
Throwing a dart, "going with your gut" or just upgrading what you already have might work for you, but if you want to have confidence, and build confidence in others, that a particular path forward is the best one for your organization, then you need to document your requirements, and then fairly and transparently evaluate several viable options.
But I've Already Done This
To be honest, most weeks, I talk with organizations who say they have already done most of this. So here’s a simple test. If you have indeed done this well then you are moving forward and implementing, migrating and transitioning to your selected end state. You have a project team, a project plan and weekly status reports.
If on the other hand, you did some analysis, maybe even made a recommendation, but you or others in your organization remain unsure, uncertain or undecided and you find you are not moving forward, then there is more work to be done.
At one company I worked with, for the whole of 2010, the CIO said he was 95% convinced of the correct direction. Needless to say, not much got done in 2010. Being done is being 100% decided and having the necessary agreement from other key members within your organization.
If you are continually discussing and debating Cisco CUPC versus Microsoft OCS/Lync versus Avaya One-X; or Modular Messaging versus Unity versus Call Pilot versus Exchange Unified Messaging; or whether to move to Office 365; or whether to move from Centrex; or Direct SIP versus CuciMOC or CuciLync; or Meeting Place Express versus Web-Ex versus Live Meeting...then you have some more analysis work to do.
It Takes Effort and Time Evaluating options and planning the best path forward takes a good amount of time and a fair amount of effort. For medium to large organizations I find this process takes a minimum of 20 to 30 person-days of effort over an 8-week period. You need to invest this much time in order to do an analysis in enough depth to provide real value and direction. You also need the people driving the process to have the expertise, experience and unbiased outlook to transparently evaluate the options.
This approach takes time; but making the right choice, choosing the best path, can provide Goldilocks' "just right" feeling.
Summary
Just then, Goldilocks woke up and saw the three bears. She screamed, "Help!" And she jumped up and ran out of the room. Goldilocks ran down the stairs, opened the door, and ran away into the forest. And she never returned to the home of the three bears.
But because Goldilocks knew how to make decisions, before she left, she provided the bears with a communication system that met all of their key requirements. And even though Goldilocks was far away, the bears could call, instant message and video conference with Goldilocks any time they needed.
And they all lived happily ever after.
