"[I]f you cannot articulate your business needs and identify IT products that can help you fulfill those needs, you end up thinking in terms of concepts...And when that happens, the marketing departments have got you. No matter how objective you think you are, you will inevitably find yourself choosing a brand name."
Open source telecom platforms have matured to the point where they are often functionally superior to more traditional products. A case in point is asterisk, an open source PBX (private branch exchange) and telephony engine, which was recently named "best IP PBX" in InfoWorld's 2008 Technology of the Year Awards. While industry recognition can be a compelling argument for adoption, it is still difficult to stake one's reputation on the implementation of any software in a mission-critical solution without having first built a solid foundation on which to do so.
With the right approach, you can deliver a superior open source solution to your telecom problems, at far less cost than using proprietary offerings. Implementing an open source telecom system is similar to any development project: there are steps you can take to lower risk and ensure a successful result. This article provides a practical approach for technical implementors to build a track-record of success that will help win approval for more challenging business initiatives.
Start with a Business Need
When you look into the potential of an open source telecom platform, it is easy to become excited at the technical possibilities. Asterisk can provide any functionality required of a telephone system, as well as other features that probably have never been attempted before with a telephone system. This does not mean, however, that you should dive right in and attempt to implement a fully database-driven, mission critical IVR (interactive voice response) system with speech recognition and web-integration. Yes, such things are possible, and even relatively easy to do, once the right skills are obtained. But the sage advice is to start small, and build on success.
In far too many projects, the focus is on the technology, not on the organizational problem that is being solved. This is risky behaviour regardless of the project, but in an open-source project, where there is often a perception that the technology is hobbyist-grade, it is doubly important to focus on the business need. Find a simple problem that needs solving, that is not overly complex, and that can be implemented within a reasonable budget.
The needs analysis can be challenging. Many businesses don't know exactly what they need. Moreover, traditional telecom systems tend to be inflexible and many companies have developed a defensive mindset towards solution brainstorming. There can also be political pressure to go with a shrink-wrapped solution, as there is a perception that this is a lower-risk approach. Don't hide the risks. You will build more credibility for your case if you show that you have a balanced approach to the challenge, and have considered the downsides as well.
When preparing for the needs analysis, consider the following:
- existing politics can introduce illogic such as a perceived threat to job security
- there may be pressure from existing vendors to maintain the status quo
- humans don't like change
- if you can't discuss the ROI (return on investment), you're not prepared
- your idea might not save as much as you think--be aware of the hidden costs such as training, patch management, and ongoing support
Skunk Works
When first implementing an open source solution, it is probably wisest to fly below the radar. The more noise you make regarding your implementation, the more any failures are likely to be blown out of proportion. Under-promise and over-deliver is your mantra.
Do lots of prototyping work. From that work, you will be able to determine whether what you are trying to do is, in fact, doable. In many cases, the little things that you didn't think about could prove to be show-stoppers. Better to find this out before too much is riding on the project.
Do not show anything you are developing to the naysayers until a working prototype is available. Naysayers focus on the problems, rather than the potential. If problems exist with the prototype, make sure you are the one that identifies and explains them. This will demonstrate that you are on top of the situation, and defuse any criticism before it begins.
Don't waste too much time on the "cool" features of your solution, but keep your focus on the business case. You will look far more professional this way.
Whenever possible, find an executive champion who believes in your solution and who can assist you in demonstrating a balanced approach to the solution. Remember that open source projects are often perceived as high risk and that the rewards may seem obvious to you, but not necessarily to others.
Hiring Outside Talent
At the early stages of adoption, it can be helpful to have access to experienced talent. While the whole reason to use open source can be to reduce dependence on outside vendors, this does not mean that enlisting some experienced help is a bad idea.
When you engage a consultant, you need to do your research by checking references and using Google. The consultant should be someone who is active in the open source community as this increases the likelihood of good access to the development team.
If your goal is to hire a consultant to get your implementation started, and then take the technology in-house, make sure the consultant knows this and there is a plan in place for the consultant's exit. If there is no plan, you run the risk of a longer-term dependence than originally anticipated and budgeted.
Planning The Project
Once you've produced a successful prototype, received buy-in from affected parties, and have the go-ahead, the real work begins. In order to ensure success, there are some basic project management strategies that will ensure that your first open source telecom project is not your last.
First and foremost, you need to manage people's expectations. When the question "can we do ?" arises, the best answer is "yes, but I recommend we put that off until phase two, in order to ensure that we keep the risk level in phase one as low as possible". Second, you need to have a well defined scope. No project is immune from the possibility of scope creep, and this is arguably one of the surest ways to kill a project. When you are getting pressure to change the scope of the solution halfway through the project, you need to resist the temptation to be the hero. Either push the change off to phase two, or push the due date for phase one. Using project management software that allows you to produce a Gantt chart or some other visual representation of the project will allow you to show how a seemingly minor change can have seismic repercussions.
Third, don't trust the white board. People often make all kinds of wild assumptions during planning sessions, with little or no regard to what actually exists in reality. Pre-survey as many details as you can, because it will save you a ton of grief, time and expense. Most people learn this the hard way.
Fourth, pay attention to the basics of customer service. Treat the end users and stakeholders as if they had purchased the solution from you. Take the time to listen to their concerns, and make sure that a comprehensive support and training plan is included in the scope.
The Cutover
Once the system is built and ready to be put into production, several techniques can help to keep this stressful event as painless as possible.
First and foremost is to beware the partial cutover. During even the most well-planned projects, there can be a time when the fear of change rears its head. This will often appear as a panic-induced pressure to do a partial cutover. Never do this. Either cutover to the new system, or don't, as a partial cutover will be a disaster. The reason is simple: nobody planned for a partial cut, so what you have is a totally different system from either the new or the old, without the benefit of any planning. Naturally, this disaster will be blamed on you or your project. Also note that if you do not go ahead with the cutover, there is a good chance that you won't get a second chance.
On the first day following cutover, you may be faced with angry people. This is an unfortunate side-effect of the disruption caused by a new phone system. It is best to assume that this will happen so that you can prepare for it. It can be intimidating, but as long as you recognize that it is the fear of change that is talking, you will have a chance to work through it. Also, this is another reason why training is so important. Training allows everyone a safe environment to deal with the emotional impact of the new system.
Summary
From the business perspective, implementing an open source solution is very similar to implementing a solution provided by a vendor. With proper planning and a focus on the business needs being met rather than the technology being implemented, an open source implementation can be managed and result in success.