Evaluating options and planning the best path forward takes a good amount of time and a fair amount of effort. But a step-by-step process can yield the right result.

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.

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!).