If your organization isn’t thinking about unified communications, you may get that nagging feeling of being left behind in the latest communications technology promised to delivery positive business impact.

Well, don’t feel too bad now. InformationWeek surveyed a few hundred business technology professionals about UC’s impact, and the results are enough to rain on any UC parade:

The buzz around enterprise unified communications is loud, and getting more so as IT spending loosens. The problem is, in our experience and confirmed by our InformationWeek Analytics 2010 Unified Communications Survey of 406 business technology professionals, enterprise-wide UC programs that have a truly transformative impact on business processes are all too rare.

For example, videoconferencing has lately hogged the spotlight. But too often we see IT groups set up expensive video systems and walk away, with nary an hour of training or any plan to track whether employees even use the tool. From the CFO’s perspective, consumer-class applications, such as Skype and Yahoo Messenger, seem to provide much the same benefit as enterprise-class systems, without all the hassle and expense. No wonder we’re faced with frustration, misunderstandings, and elusive ROI.

Does this remind you of anything? Say, back in the days when CRM was taking off and was the buzzword in almost all business technology articles?

In the glory days of PeopleSoft and Siebel, there seemed no end to their high-flying potential. They hired almost anyone out of college who could be molded into a business/technical consultant. They signed on customer upon customer whose CTO drank the Kool-Aid and was sold on CRM’s transformative powers. The promise of cost savings, business processes re-engineered, and happy executives. Seemed like a no-brainer!

But as we all know, many of these CRM implementations failed miserably. Over time and over budget. Litigations ensued. In fact, there’s been stories of how failed CRM projects broke companies.

UC adopters: may past CRM projects serve as lessons for you. Like CRM vendors, UC vendors will promise the moon. It’s best for you to stay grounded in evaluating UC’s benefits for the organization. Executives are especially vulnerable these days because of the economic downturn, and vendors will certainly exploit that.

If you follow closely the developments in UC, you need to read the whole article.

I will provide coverage of ICMI’s ACCE Conference & Expo in New Orleans next week, bringing you the latest news and trends in contact center management. Already on the conference agenda are lots of sessions about social media, so that’s definitely on the minds of many management staff. I’m also looking forward to the keynotes, especially from John Foley, a former top pilot of the Blue Angels and now motivational speaker/businessman.

The one thing that may come up in conversations is the Gulf oil spill which has hit the state hard, and starting to have an impact on the neighboring Gulf coast states. I have read reports that some New Orleans residents have complained about a mysterious odor, but no official word on the origin. Of course, many people suspect the odor comes from the spill. At any rate, Louisiana needs our help in cleaning its shores and beaches and saving the precious wildlife from this environmental crisis. There are many ways to help, one being the Coalition to Restore Coastal Louisiana which is a local non-profit organization that’s been dedicated to the cause since 1985.

Have a great weekend and see you in New Orleans!

As we all know it takes more than technology to excel in operating a contact center. That is why I’ve decided to attend the ACCE Conference and Expo next week in New Orleans. This conference is all about contact center management, from human resources to knowledge to performance. There will be vendors in analytics, measurement, workforce management, and more. Unsurprisingly, there’s a lot of focus on social media this year as well, and I definitely look forward in learning about how contact center managers are (or will be) utilizing social media to improve their center’s effectiveness.

If you will be there too please don’t hesitate to contact me so we can meet up.

There is a lawsuit that is attracting a lot of attention among the tech systems integrators and their customers. In County of Marin v. Deloitte Consulting LLP, the County alleges fraud on part of Deloitte for misrepresenting their team resources as experienced professionals and/or experts in the SAP Public Sector implementation. The County even goes as far to say that Deloitte used this contract to provide on-the-job training for some team members. Deloitte was hired in 2005 and after all these years the ERP system is still a mess, according to the lawsuit.

Deloitte fired back with a claim alleging “breach of agreement and unpaid invoices.”

Michael Krigsman has a good writeup on ZDnet. Here’s my take stemming from my own CTI project experiences…

Integrators LOVE public sector projects

Government and municipal customers are often considered the cash cows for systems integrators and vendors. Lots of milking and lots of expensive CYA. The truth is, a public sector customer is often overstaffed, bureaucratic, and loaded with taxpayer money (okay, maybe not with the recent economic turmoil). It gets even worse if there are union workers involved. Sadly that is just the nature of government. Vendors realize this and will certainly exploit it to maximize profit and margins.

Because of the inefficient nature of government, it will take more dollars to get things done. That’s just the way it is. For each layer of management approval required for project changes, dollars are going down the drain. For each hour that’s required for reviews by everyone and their bosses, and as hours turn into days with no decision in sight, money is being thrown out the window. Public sector employees are also very risk-averse and resistant to change. They prefer to avoid accountability for fear of embarrassment, but usually when something bad happens they will just pour more money into the problem rather than admit fault.

That’s perfectly fine with SIs. In fact, SIs count on it.

I’m willing to bet that Marin County never really took control of the project. I bet the County just wanted to hire somebody to take care of everything, i.e. pay somebody (Deloitte) to make the problem (the SAP project) go away.

It cannot work that way. The customer has a duty to keep SIs on their toes. I’m not saying to constantly ask for status meetings or watch over their shoulders, but to convey the expectation that all parties will be accountable for their end of the deal.

Even better, the public sector customer can disrupt the stereotype by being flexible and open to accept better processes, new organizational changes, and being a good steward of taxpayer money. That ought to shock the integrator.

Technical complexity requires simplifying everything else

The more complex the system, the better it is to streamline and simplify everything around it. That means cut down on paperwork, flatten the team organization, and streamline the processes.

Who wants to deal with a five-day waiting period before a firewall port can be opened? Who wants to get that phone call from AP about a missing $1 receipt for that Coke you got at the vending machine? Is it really necessary to ask for VP-level approval for taking just a few days off?

Having to deal with crap (yes, that’s a technical term) like that only puts additional burden onto the team which I’m sure is already inundated with technical challenges and deadlines.

Technical ability doesn’t guarantee success, integrity does

Yeah, yeah, yeah. I know what you’re thinking: Eugene is high on crack. But I firmly believe that many issues and problems facing troubled IT projects are results of dishonesty and unethical behavior, applicable to both the SI and the customer.

Technical problems are almost always solvable in today’s environment. Perhaps it’ll take some more time and money and manpower, but it shall not hinder the ultimate success of the project.

Big SIs will lie to make more money; small SIs will lie to survive. It’s that simple. If you work for an SI then you should do everything in your power to maintain your professionalism and integrity. It will pay off in your long term career.

What gets the project in trouble and pushes it to the edge of failure? Dishonesty about team resources, dishonesty about expenses, dishonesty about existing IT systems, dishonesty about payments, etc.

Closely watched lawsuit

The outcome of this lawsuit could have far reaching effects. Just think of the number of IT projects that aren’t deemed a success. Add on to the fact that many SIs today rely on outsourced resources (some even offshore) which definitely complicates matters.

What’s your take on this litigation?

The world is a happy place with traditional queue-based routing. Telecom administrators can set up queues on the PBX easily — blindfolded, standing on one leg, with one arm tied to the back. Contact center managers can precisely illustrate what they expect in regards to queue-based routing… A queue for premier customers, a queue for Spanish-speaking customers, a queue for late payments, etc. Everything in the contact center is in harmony.

Then somebody had the idea to throw a wrench into the whole deal: skill-based routing. Don’t think about your agents as members of a queue (or queues), but instead think of all the skills they have to serve the customer. Ah, ingenious! And so customer focused!

But here’s the problem. Many PBX administrators and contact center managers simply have a hard time wrapping their heads around SBR. QBR is so ingrained in their lives that anything straying from queues will cause confusion. And if not confusion, obfuscation. That is, their attempt at QBR-to-SBR transformation often results in a implementation and maintenance disaster.

Traditionally, there’s a license fee associated with a PBX queue. It’s like any other phone extension, except having different characteristics. So consequently contact center managers understand not to go crazy with queues.

But with the newer PBXs and contact center servers supporting SBR, these managers found out that there’s hardly a limit on the number of skills. They can set up hundreds and hundreds of skills (hey, it’s a big enterprise!) with ease and have fun assigning them to agents. In fact, it’s so easy that I’ve found in my previous projects that some supervisors will change agent skills on a daily basis. (So today this agent has the Spanish skill but tomorrow she won’t.)

Plus, it’s quite often that they will not let go of queues. They want to keep the queues for overflows or as a catch-all bucket to dump calls, i.e. if a caller is holding too long in SBR go ahead and dump the call into a queue. The caller probably wouldn’t enjoy that experience any more than having remained waiting for a skilled agent. Essentially, the contact center now becomes a mixed QBR and SBR implementation. That translates to more effort in terms of design, deployment, testing, maintenance, and troubleshooting.

If SBR is in your future then by all means totally commit to it and learn to forget about queues, even to handle overflows and catch-alls. Invest in a virtual hold or callback integration instead of resorting back to QBR. In the planning and design phase, also bring out the agent training materials to grasp a better idea of what constitutes an agent skill. Go through a few iterations to define skills until you’ve got a set of skills that’s manageable and easily maintainable down the road.

And if you’re just satisfied with good ol’ QBR? Well, there’s no rush to join the SBR crowd. According to a friend who works at a major telecom company which also offers managed hosted (cloud) services for contact center infrastructure, he hasn’t seen one customer using skill-based routing…

Countless researchers and managers have commissioned studies on why major projects fail in order to achieve a higher percentage of successful implementations. Was it the vendor? The equipment? The culture? The timing? The budget? The resources? JUST TELL ME WHY IT FAILED!!!

Yes, it can be quite frustrating and sometimes it could even cost a person’s career…

But I came across this blog post on AnswerNet with a simple (possible) answer: silence:

Research carried out by training company VitalSmarts and professional services firm, The Concours Group, uncovered five crucial issues – what they term “crucial conversations” – that have an enormous impact on whether high-profile business initiatives ultimately succeed or fail.

The study, “Silence Fails: The Five Crucial Conversations for Flawless Execution”, suggests that when even one of these crucial conversations fails, a silent crisis plays out in a relatively simple dynamic that results in initiatives failing 85% of the time. The result of this failure sees projects going over budget, missing deadlines and failing to meet quality and functionality specifications.

However, when these conversations succeed, according to a survey of more than 1,000 executives and project managers across 40 companies found that the failure rate is reduced by 50 to 70%.

Those are astounding statistics! And what are the “five crucial conversations”?

1. Fact-free planning - the scenario that sees a project is set up to fail from the beginning with deadlines or resource limits that are not grounded in reality.
2. Absent without leave (AWOL) sponsors - managers who fail to provide the leadership, political influence, time or energy to see a project through to completion.
3. Skirting - when people work around the priority-setting process and are not held accountable for doing so.
4. Playing chicken - when team leaders and members don’t admit when there are problems with a project but wait for someone else to speak up.
5. Lack of feedback - team members perpetuate dysfunction when they are unwilling or unable to support the project, and team leaders are reluctant to discuss their failures with them candidly.

Now look back on your past projects or even your current projects, and do an honest evaluation of these bullet points. Is your project on the path to an inaudible self-destruction?

This post is solely based on my past experiences in the field as a developer (IVR, screen-pop, and call routing applications) and as a consultant (business analysis, design, architecture, etc.)… I have not conducted any sort of scientific polling or studies to confirm this, so it’s purely a personal observation…

Perception

More often than not, contact center projects are run without regard to any sort of methodology, especially software development methodology, when programming tasks are involved. It is unfortunate and I believe a contributing factor to a high failure rate of contact center projects.

One of the hurdles to overcome is perception. It seems that there’s a perception gap between the understanding of traditional software development versus, say, IVR app development. Traditional software development utilizes common tools and IDEs to enable the developer become more effective in writing code, be it C++, Java, or whatever. These tools normally come with comprehensive debugging and simulation features to facilitate the development life cycle. The developer can quickly find out and demonstrate whether or not his (or her) code works per customer requirements.

Contact center app development, on the other hand, is regarded as some sort of magical stew with telecom, IT systems, and developer know-how all mixed in. But it really is similar to traditional software development except with more constraints: the tools are likely to be proprietary, debugging and stimulation features are lacking, and testing usually requires a coordinated effort between telecom, IT systems, data networking, and more. So the catch is to effectively manage the development life cycle with acknowledgment of these constraints and to work within them.

Design

Most importantly, don’t skip the app design phase — no matter how tight the project time line is. The requirements document (yes, it’s recommended to have that too) should be the Old Testament, and the design document is the New Testament. Together they are the project’s Bible. Seriously, I have seen my share of project management ignore a good, documented design, and what happens? The project may be off to a decent start with the developer coding away, perhaps proudly demonstrating some rapid prototyped app to everyone’s delight. Then sometime in the middle or tail end of the project a major flaw is uncovered or updated customer requirements warrant a new design — and all hell breaks lose. At this point the project team will take either one of these routes: 1) Go back to the drawing board and really spend time to finally document and update the design; or 2) Go into panic mode, apply band-aids to gaping wounds and use fingers to plug holes in the dam.

More often than not, it’s option 2 that gets chosen because it has the illusion to be the path of least resistance. To a panicked and undisciplined developer, option 2 will result in spaghetti code. Lots of duplication, hard-to-understand functions, hard-coded values — the works. That IVR or routing app, once affectionately called a cute little furry critter, all of a sudden grows into a hairy monster who hasn’t showered in years. Instead of correcting the critical mistake when there was still enough time and resources, now it becomes a software development lifeless cycle in a death spiral. Get the picture?

Development

I’d also recommend a development phase with a more collaborative and peer-friendly methodology (a la Extreme Programming). Instead of a solo developer, engage two of them. Not only is this good practice in times of unpredictable situations (illness, family emergency, etc.) where a second developer resource is readily available to take over, but also having peer reviews or peer programming significantly reduces defects and shortens testing times.

I can attest to the effectiveness of a peer programming methodology even in a contact center project. A coworker and I were developing an IVR app together, and after coming up with the design we split the work into functional chunks, and sometimes even sat in each other’s cubicle watching over the other person code. We were able to quickly implement algorithms, point out each other’s mistakes, bounce off ideas, and even take over when the other person had to step away. As a developer it was a great collaborative and satisfying experience. We delivered the IVR app ahead of the deadline and with minimum defects.

Okay, I can see you PM types frowning, But there’s no budget to acquire two developers! In that case, instead of just a pure business analyst resource, acquire one who’s also an experienced developer (most developers can handle BA tasks well). Or let’s hope that you (the PM) can also wear a developer hat. Yes, that’s how much I believe in this aspect of software development, even in contact center applications. Two developer brains are definitely better than one. And if you really must have only one developer, you will appreciate the time spent in the design phase to produce a quality design document. (God forbid the lone developer leaves the project, right?)

Testing

When it comes testing time, make sure all documents are in order. Test against the documented requirements first, then turn testers lose to detect any exception conditions. The best testers will be those who fat-finger a lot but are detail oriented. If it’s a DTMF IVR app, make sure to go through all the menus and key combination. If it’s a speech app, make sure testing is performed with landlines, cell phones, loud voices, quiet voices — you get the idea. If it’s testing routing and agent screen-pop, make sure to simulate what a rookie (or absent-minded) agent might do. I’ve had heard horror stories of systems going live — after a successful system test and user acceptance test — only to fail miserably in the real world for various reasons. Reasons which could’ve been predicted and implemented during testing.

Your thoughts?

Do you think there’s a place for software development methodology in a contact center project? And what are your own experiences?

Oh yes, the ubiquitous Redial button on modern telephones. We take it for granted all the time as it helps us save time and the energy of lifting our fingers to press more keys. It allows us to free our brain cells for more important memories, such as remembering 911 and the number to the nearest pizza joint. It is probably as important an invention as the wheel, the light bulb, the transistor, or even — gasp! — sliced bread.

What happens when the Redial button is absent on a phone?! That travesty of a phone indeed appeared during one of my past projects. A team member very much needed to repeat his previously dialed number which was written on a piece of paper. But there was no button labeled Redial on his desk phone, so naturally he raised his fist and cursed the PBX gods to no end.

Being the snarky member of the team, I made a profound, almost Zen-like remark to him: Of course there is a Redial feature, it’s a 10-key redial.

He was not amused, and I quietly went back to pretending to be busy at doing something CTI-ish.

But there is a lesson here… and that’s to avoid taking any simple technological feature for granted. Furthermore, always remember how to do things the “old” way.

In all CTI implementations there is a law. The law simply states, The contact center agent cannot live without CTI once it has been deployed successfully. In other words, an agent becomes dependent on the softphone and screen-pop, unconsciously taking CTI for granted. Remove CTI and the agent becomes incapacitated. AHT and call abandoned rate start going up and now the supervisors start freaking out. Soon enough the whole center becomes a zoo showcasing animals with headsets attached to their ears.

I propose that every well-managed contact center ought to schedule drills to simulate a CTI “system down” crisis. Take the CTI system offline and instruct the agents on how to continue to take calls, be courteous to callers, and continue to perform their tasks effectively. It should be part of the staff training. Go back to the analog technologies — pen and paper — if necessary. As long as calls are still arriving at the center then there is absolutely no excuse to make customers suffer because of your staff’s addiction to screen-pops.

In my past projects I have never seen a client implementing such a drill. Most of the time it was just documenting procedures for a CTI down scenario. Perhaps we all have overwhelming faith in CTI technology for it to be near-perfect? I don’t know about you, but my cable broadband goes down once in a while and my cell phone still drops calls in 2010.

I dare say that contact center project failure rates are similar to those of CRM project implementations:

• 2001 Gartner Group: 50%
• 2002 Butler Group: 70%
• 2002 Selling Power, CSO Forum: 69.3%
• 2005 AMR Research: 18%
• 2006 AMR Research: 31%
• 2007 AMR Research: 29%
• 2007 Economist Intelligence Unit: 56%
• 2009 Forrester Research: 47%

These numbers do not look promising. I also believe that contact center projects are often more complex than CRM ones.

Implementing a contact center project often requires the participation of technical expertise from telecom, networking, databases, desktops, and enterprise applications, and operational knowledge from senior management, supervisors, and of course, contact center staff. Not to mention occasional involvement of external vendors like the telephone carriers and any outsource organization.

Based on my project experiences, I believe the following are critical in ensuring a successful contact center project:

Hire a technical project manager. There are people who propose that a PM doesn’t need technical knowledge in order to run a successful project. That may very well be true, but with a contact center project it’s best to find a PM who is not afraid of digging deep into the technology and also having good PM skills. Contact center projects are complex because they touch upon so many technologies, and a technical PM would definitely add tremendous value to better the odds of success.

And picking a PM who isn’t liked by clients but gets things done is probably good. To paraphrase a PM friend and ex-coworker of mine, Don: If the client doesn’t like me then that means I’m doing a good job for the project.

If your own organization doesn’t have somebody suitable, then by all means hire from an outside source. I have seen too many cases of clients trying to save money by installing one of their own to run a contact center project. Even if this person is the start IT guru within the company, he’s almost useless if he doesn’t have the telecom knowledge required.

Vet the team members. Assemble the project team as if you are running a political campaign. Interview each team member, call out their skills and experiences in their resumes, ask for multiple references (from past clients and peers), and scour the Web for information about them. Why? The contact center industry is quite a niche, so that presents two problems: 1) Good people are hard to find; and 2) Bad people get away with pretending to be good.

And because of #1 many clients often settle with whoever they can afford to pay without vetting the contractor. The good news? Because it’s such a niche group of people, you can probably get plenty of reliable references easily.

Question the technical promises from the vendor. How do you know when a salesperson is lying? Well, you won’t know unless you know who and what to ask. Again, this is why it’s important to have a knowledgeable resource in contact center technologies readily available, especially during the sales demos and presentations. The contact center business is highly competitive, and with dwindling margins to be made in professional services, more often than not the profitability of a project depends greatly on making the sale — unfortunately, sometimes with empty promises.

Understand that there are technical limitations to CTI because the software depends on the telecom equipment, primarily the PBX. To make matters worse, there are half a dozen major PBX vendors each with their own implementation of CTI messaging. Therefore, if your enterprise consists of multiple PBX platforms, it’d be unrealistic to expect that the CTI or softphone works the same everywhere. If a salesperson makes a pitch that the desktop experience will be the same throughout the enterprise in a mixed PBX environment, then he or she is not being completely truthful.

The other frequently made sales pitch is for additional software licenses and hardware in order to implement a redundant system. Sure, redundancy is wonderful and makes the bosses think you’re doing the right thing for the company, but think carefully about the necessity and various architectures to support it.

In a typical contact center, having the CTI system go down isn’t the end of the world. So your agents don’t get screen-pops and can’t use the fancy softphone — big friggin’ deal. If the PBX is still operational (and most of the time it will be), you have no excuse to run around like a headless chicken. As long as the PBX is up the contact center should not lose calls and can continue to provide service. Obviously the talk time and wait time may suffer a bit, but your agents should have been trained on dealing with a no-CTI situation; in other words, they should still remember how to do their work prior to the CTI implementation — with pencil and paper if required.

If you must have redundancy (for example, your boss needs to burn the remaining IT budget), then determine the failure points first. Concentrate on how to remedy single points of failure in the system. Sometimes you won’t need more hardware but just a well-documented and well-executed procedure.

Avoid being an excessively demanding client. That’s right. Sometimes a project fails because the client is way too difficult. The vendor gives you the best-in-class hardware and software, the contractors work their butts off to design and implement an awesome solution, and the PM is pushing everyone to make deadlines and stay within the budget. All that won’t help a bit if you, the almighty client, is acting like an ass.

I had worked on a project once which the client team never had anything good to say about the product and the project. Constantly we’re hearing complaints and gripes and accusations from the client during the implementation. The client site was a black hole of negative energy that’ll suck your soul dry. They were arrogant, demanding, and near habitual liars.

Nobody likes dealing with assh**es because guess what? Everybody already has one.

Do you have any other tips or insights to share regarding contact center project implementation?