Over a decade ago, I was at the final interview to become a business analyst for a bank enterprise pricing and billing system. The executive interviewing me, in the interest of full disclosure, told me that the customer base was very angry. To calm them down, the company had promised to hire a business analyst with a finance background and banking experience. Wanting to understand fully what I was signing up for, I gingerly asked, “Okay, why are they so angry?”
“Well,” he said, “In the last release, we gave them everything they asked for. And they hate us for it.”
I went ahead and joined the company, and the next few months were, to say the least, interesting. After all, I had stepped into a situation in which a majority of customers were threatening to withhold their annual maintenance dollars. Before I could contribute to fixing the situation, I first spent time researching how we gotten here in the first place.
The company had followed what management had thought was a customer-focused development strategy. Management had asked the customer base to submit business requirements for proposed enhancements to be voted on for inclusion in the next release. The bankers had taken to this with gusto. They had downloaded the forms and submitted a wide range of business requirements documents (BRDs) that addressed their needs of the moment.
My company had published the BRDs online, in a secure environment, so everyone had a chance to review them. At the next user conference, a user from each bank sponsoring a proposed enhancement(s) had answered questions. After the discussion and QA had concluded, each bank was asked to rate the proposed enhancements in order of priority. Management had promised that the Top 10 enhancements would be included in the next release.
After voting, the winning BRDs were given to Development, and the hardworking techs did their best to incorporate the customers’ abbreviated, often confusing, and frequently self-contradictory requirements into a mission-critical, enterprise pricing and billing system.
The results had been, quite frankly, bordering on disastrous.
And this was the mess I had been hired to fix.
The first thing I did was throw out all the internal technical specifications and went back to the original BRDs written by the customers. I read them with a fresh eye, and then scheduled conference calls to speak to the original authors. I spent hours on the phone with them getting to the bottom of their real needs and documenting them. I explored a lot of scenarios with the users, and built up a much more complete understanding than was available from the original BRDs alone. Based on these efforts, I quickly came to realize that my company’s initial attempts at coding solutions had fallen short of addressing the underlying business objectives for many of the enhancements.
The coders had put their spin on what were, in many cases, rather sparse documents. Lacking use cases and other critical details, the coders had done their best to provide what they thought the customers were asking for. In many cases, the functionality delivered had simply not met the real needs. Customers had spent money on upgrade projects, only to discover that they were no better off than before in crucial areas.
After getting an understanding of the authors’ objectives, I reached out to other users from our user community. We discussed the enhancements and how they would or would not be useful in their banking environments. I then began to expand the scope of many features and made them more capable of handling a broader range of requirements through configuration. The goal was to have a flexible, adaptable set of features that could be deployed in a variety of ways, rather than narrow, tailored features that solved very specific problems.
One more step was doing market research. While my banking customers were very smart people, I had noticed that many of them were trying to solve business needs that had been plaguing them for some time. I was curious about not only where we were today in the market place, but also where we might be headed. I took time to look at the broad trends in banking and commercial services, even going so far as to reach out to industry experts for their opinions. The information I gathered helped guide my thinking as I put the finishing touches on the new requirements documents.
The next step was to review my new requirements documents with the user community and to re-prioritize as needed. As I had expected, when full requirements with flexible, proposed solutions were placed in front of them, the user community chose to prioritize the enhancements differently than in the original round of voting.
When my BRDs were complete, I sat down with Development to review the requirements, answer questions, get critical feedback, and analyze the scope of changes needed to the current release. At the end of the reviews, Development estimated the level of effort to get to where we needed to be on each enhancement.
The Level of Effort allowed me to work with management in planning what could be realistically incorporated in the next release. Before, management had promised to include the Top 10 priorities of the clients, regardless of Level of Effort. A blank check had been written, but all companies have limited development budgets. I had figured out during my review that, on some big-ticket features, Development had been on the right track but had run out of money. Features that should have provided major benefits had been left only partially finished. By creating a realistic budget, we could create a road map to meeting all requirements based on customer priorities.
It was not easy. Not at all. But over the course of the next two releases we managed to get new, robust, market-leading pricing and billing enhancements in the hands of our customers. Trust was restored, and user group meetings lightened up and became much more enjoyable. Customers began lining up to migrate to new releases, and sales picked up as the new features proved increasingly attractive to new banks. It is truly amazing how successfully companies can be that learn to effectively listen to their own customers.