In This Issue:
- How to Avoid Project Failure
How to Avoid Project Failure
By Peter Leppik
Any large technology project carries a great deal of risk, and technology deployed for customer service is no exception. According to a study by the Standish Group, 30% of technology projects will be cancelled, 52% will be over-budget (by an average of 89%), and only 16% will be both on time and on budget. In large companies, the picture is even worse, with only 9% of technology projects on time and on budget.
Deploying technology in customer service presents unique problems and risks. Your customers may not be very forgiving when something doesn't work properly. You often can't train customers, so ease-of-use is critical. And any problems in switching to a new system can cause hold queues and call times to explode.
Unfortunately, it can be very tempting to cut corners, especially if a project seems to be at risk. Those are exactly the times when attention to detail will be most important.
Use Business Goals as Project Goals
Success or failure often begins before the project even kicks off. Specific project goals, for example "Provide a speech recognition interface to check account balances," should be matched to success criteria which can be directly measured and which reflect business goals. For example, a success criterion might be to automate 95% of all account balance transactions.
It is also important to document existing processes, as this will inform both the project goals and ensure a smooth transition. It is essential to know what information is currently collected and how it is used. It is also useful to know what other elements go into the complete transaction. For example, if 60% of callers asking about their account balances also make a payment during the same call, this knowledge can help design a better application.
For larger projects it is a good idea to do a proof-of-concept. This small-scale test is designed to discover whether the business goals of the project are feasible. For example, you can build a functional mock-up of a speech-recognition application, test it, and compare it against your existing operation. At the cost of a few weeks time and a few percent of the total project cost, you will have a good idea if this project is likely to succeed.
Understand the Customer's Needs
In the projects we see at VocaLabs, the overall goal is often to automate a process currently handled by live agents, or upgrade existing automation to improve customer usage or satisfaction.
This requires knowing, in some detail, what the customer is really trying to accomplish, and how he or she wants to accomplish it. At the design stage, you should invest in testing different designs of the system to discover how the callers expect to use it. Without this data, the odds are good that callers will find the new system difficult or confusing to use, and simply go back to talking to live agents.
Align the Vendor's Goals with Your Own
Projects often fail when the company and the vendor begin pursuing their own agendas over the success of the project. Success is easiest when everyone's goals are in sync.
Acceptance criteria which are tied directly to business goals are the best way to make sure everyone is on the same page. For example, if the business case requires that 95% of certain transactions be fully automated, then that should be an acceptance criterion.
The vendors will protest, of course. In the present economy, however, you have a lot of leverage, since few vendors have customers banging down their doors. If the vendor is not happy with a particular criterion, ask the salesperson to suggest a number he or she is comfortable with. To avoid later disputes, the acceptance criteria should be numerical, concrete, and evaluated by a neutral third party.
Using business goals as acceptance criteria ensures that the vendor is completely motivated to ensure the project's success. There is no benefit for the vendor to use unrealistic assumptions, promote project creep, or otherwise undermine the project's success to get the sale.
Avoid Project Creep
We've all seen project creep. Once a project starts, new features are added, new functionality gets defined, and pretty soon the original project is like the falling pebble which triggers a killer avalanche.
Promoting project creep is in many people's interest. The vendor wants a larger project (unless you're using business goals as acceptance criteria, as we suggest above). People in your own organization see an opportunity to attach their pet ideas to a funded project. And some people just like playing with cool technology.
To avoid this pitfall, you need to rigidly enforce the original goals and success criteria of the project. Indeed, as the project progresses, you may discover that you have to abandon some goals to ensure overall success.
Anything which is not included in the initial phase can be considered for inclusion in the next revision. The only exceptions should be if something is discovered which makes overall success impossible without increasing the scope of the initial phase.
A series of meaningful project milestones will ensure that the project stays on the planned timetable. If a milestone can't be met, then the milestones don't match the project: either the project is too large for the timetable, or the timetable is too aggressive for the project.
Most organizations prefer to trim the scope of the project, rather than push the timetable back. Either one is acceptable, as long as the milestone is made realistic.
The mistake to avoid is throwing more resources at the project, in the hopes of accelerating it. Given the time it takes to bring new people up to speed, and the management challenges when working with a larger team, the likely result is a project which is now over-budget and past-deadline.