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…
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.
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?
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?)
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.
Do you think there’s a place for software development methodology in a contact center project? And what are your own experiences?