Tag: shoretel deployment

ShoreTel – Does a “single image” deployment always make sense?

Posted on by DrVoIP

We continue to be a major fan of ShoreTel solutions, but that does not mean that they we accept everything without question.  One of the most touted advantages of the ShoreTel architecture is the concept of a “single image” solution with no single point of failure.   We find that in large enterprise deployments that may not be an advantage.  Just because you can deploy as a single image, does not mean that you should!  Lets take a closer look at this battle cry and test that claim against real world situations for large enterprise deployments.

First, the concept of a “single image” system.   All phone systems, bar none, have to deal with the realities of a database.   Generally a phone system has two databases;  the configuration database and the run-time or state machine.   Again, all telephone systems have the same challenge as there can only be one copy of the primary data base.   In a ShoreTel system, the primary database through version 10 was located on the HQ server.    If you lost the HQ server, you could not make any changes to the system configuration.  This meant agents could not log in or out of workgroups and automated attendants could not change from day to night mode.   If a user, as another example of a “state” , had their calling mode set to “out of office”  you were going to stay absent until the HQ serve came back!

Lets consider a large system deployed over several time zones.  Assume a HQ server in the PST zone and a workgroup in the UK on GMT, with maybe a few branch offices in the EST and CST!    Any network issues, even a simple flapping WAN, will result in the UK agents going off line and not being able to log back in.  After Version 10 ShoreTel implemented “distributed’ databases and optional, distributed workgroup services.  You had to make a choice however, either you could distribute your database or you could distribute your workgroup service, but you can not do both.    As you can have one but not the other, it seems that though the workgroup service might be available the current state would not be available to change.  What does this mean?

If we distribute workgroup services, in the above example, away from the HQ server to a distributed server running in the UK,  ShoreTel workgroup functionality would be enabled for  continued operation in a WAN down scenario.     Agents, however, would not be able to change their states from log in to log out or back again.   This is because the availability of the only read/write database is still unavailable.  ( Generally, we would recommend that workgroup services , in a large ShoreTel deployment, not be distributed for this reason, opting to have the ability to change call handling modes and have workgroups fail over to hunt groups).

Nobody that has had responsibility for maintaining or upgrading a multi-site deployment with the geography as defined above, would ever vote for a “single image” solution!  Imagine organizing an upgrade for the above scenario?  All of the servers, switches and phones across all time zones would have to be upgraded in a single maintenance window.   Then again,  this might have been the wrong deployment model to begin with!  Just because you can install as a single image, does not mean you have to deploy using a single image.   The above scenario could have been deployed using two separate systems, one in North America and One in Europe.   They could have had a uniformed dialing plan that would have masked the two system as a single system to the users, through a SIP tie line between the two systems.  Clearly, they would have had two voice mail systems and two administration portals.  On balance, however, it  might be a more stable model with less operational head aches and certainly a lot more manageable when it came time to upgrade!

Then again, that deployment strategy model would look an awful lot like a CISCO deployment!

Deploying ShoreTel – A project managers notes!

Posted on by DrVoIP

Having deployed literally thousands of phone systems of all sizes and levels of complexity, we have distilled a set of rules and check lists that work.   (see our “network readiness check list” and our “VoIP planning guide”) When phone systems were analog or traditional TDM based solutions,  deployments were challenging enough!  You always had the User group, Call flow and “K plans” to hammer out along with the usual Telephone carrier challenges.  With VoIP solutions however, the level of complexity has dramatically increased.  This technology touches so many other infrastructure domains that it is becoming increasing more difficult to draw a box around what is included in the project!   Consider that you are required to  integrate a phone system with Active Directory,  Exchange, CRM applications and deploy over a geographical topology that might be global in scope!  You need a road map for success and  project management becomes an essential component of a successful deployment.

The first post sale step should be to organize a “kick off” meeting.  The kick off meeting  is an opportunity to set expectations and establish guidelines that will help complete the project on time and within budget. When you leave the kickoff meeting, everyone on the project team must be on the same page.  It is imperative that we identify the key “stake holders” in this project.  Minimally this list has to include an Executive sponsor, the Account manager and the Project manager.    During this meeting you will want to spell out goals, objectives and deliverable identities then obtain “buy in” from the kick off team.   You will introduce the project team members and identify their individual “roles and responsibilities”.   Setting a target for “go live” often helps drive the milestones that have to been executed if that time line is to be achieved, so I am a big proponent of working backwards from a target date!   Developing a contact list should be accomplished at this meeting and if the project will use a web portal for communicating, it should be demonstrated.   Allow for the possibly that there may be outside vendors that need to be identified at this time and added to the contact list.  Finally, assign “home work” and set due dates for the next meeting.

The kick off meeting is almost a social event and is a time for people to associate names and faces.   It is not a working session, but an effort to set expectations for all that will be either on the project implementation team or will be impacted by the implementation process.   There is a wide range of personalities and skill sets at a “kick off meeting” so it is important to adopt a language that is comfortable for all.  The team will consist of very technical people, financial  professionals and technology consumers (We are trying to avoid using the work “users”.  There are only two industries that call customers users.  The IT community and the drug trade).   It has been my experience that we will almost always get all of the technical stuff settled; all the speed and feeds, bits and bytes.   The area that is always the most difficult to extract is the Call Flow information .  For this reason it is imperative that the team have a representative that can speak for the User group.   Someone has to define a callers experience and the scripts that are head by the caller as they progress through the telephone system (see also: http://www.blog.drvoip.com/call-flow-the-callers-experience-when-reaching-your-business ).

Some of the internal players that will need to be included on the implementation team are responsible for key infrastructure components.   Active Directory integration is now almost always a part of a VoIP deployment.   Messing with a companies domain and user authentication polices are never take lightly and you will need to get key intellectual resources involved to pull this off successfully.   Clearly, the computer network both LAN and WAN will touch the the new phone system and this area requires even more planning and communication.  Generally, there will be outside vendors involved especially as it relates to the WAN connectivity.   Getting the carrier to the table early on in the process will greatly facilitate the success of the project.

Facilities management or property management and the bag full of deal killing goodies needs to be addressed early on!  If you are deploying in a “greenfield” you will have a different set of challenges then if you are replacing an existing phone system.   Often a “greenfield” is another word for “new construction” and construction always means scheduling conflicts and delay.  This is where your project management software really gets exercised!

The actual deployment of equipment is almost reduced to a task list. Properly managed most of the heavy lifting has already been accomplished before the equipment is actually installed.   The network has been assessed, made ready, routes updated and QOS applied.   The user database, IVR scripts, trunk facilities, Extension lists, Hunt groups and system definition have already been programmed.   We are down to “rack and stack” and set placement in anticipation of exercising our detailed system test and acceptance process.

It is about this time that we will want to have the Training team make an appearance.    Generally, it is best to schedule user training as close to the “go live” dat as possible.  We have found that we can brake user training into two groups.  The first group is a an abbreviated session design to assure that all can answer an incoming call, park, transfer and conference.  If users can do that by “go live”  only good things can happen.    The second group is an extended session augmented by multimedia and other online solutions.  This training is for your power users and special users like Operators, Agents and Supervisors.  Actually, this is a process not an event and your training program has to be ongoing over the life of the deployment.   People come and go in any company.  Your reputation and phone system stay. Make sure new users have a good impression!

The “go live” is also more of a process than an event.   Moving the old numbers to the new phone system, might be a single task in time, but it is part of a process that includes a series of collateral events.  For example, how do we get our Voice Mail off the old system?   In fact, what happens to the old system?   Was Garbage removal in the project plan?   A new VoIP deployment needs a “post cut” support plan that includes establishing a “help desk” and identifying a problem reporting process and resolution team.

If there is a “kick off” meeting there should also be a project close and review meeting.    This is where we can review what happen and how to transition the project to a support mode.   There should be an “as built” documentation package that is handed off from the project team to the operations team.  These documents will be outdated in less than a month, but it makes ongoing support viable if we have a record of changes to date, so make the extra effort to get this package completed as part of your project plan.   Ultimately you will want to have a 30 day review.   Keeping a client takes as much effort as getting a new client, so make ongoing client contact and system optimization part of your service offering.   Include ongoing training and you should be able to keep a client for life!