Case in Point

I worked for a loan serving company that frequently purchased loans from other financial institutions. Our strength was in servicing: accepting payments, managing loan changes, and handling delinquencies and payoffs. When we bought a group of loans (often referred to as a pool), they were delivered in two parts: (1) boxes of loan documents and history and (2) one or more electronic files which contained all of the data describing each loan (borrower name, address, original loan amount, current balance, next payment due date, etc.). Rarely did this file format match ours because our loan serving system had been developed in-house. An IT loan acquisition team was assigned to each pool. The team’s job was to perform gap analysis on the data. We mapped the data and wrote a data conversion program to load the data into our systems. During one particular acquisition, I heard one of the developers say “All of this work for 50 loans!” The team was struggling because the data conversion was very complex. It occurred to me that we had never performed a cost/benefit analysis on one of these acquisitions. I wonder how many hours would have been needed to simply enter the 50 loans into our system through the data entry screens. My guess is that we would have saved a significant amount of resources on these smaller pools if we would have converted them manually. But we were in the habit of converting these loans in the same way.

There are several common reasons why an organization decides to fund a project:

• Because of a problem

• To eliminate costs (jobs)

• Outside regulation

• An opportunity

• For marketing or advertising

• To align business processes

Project Initiated Because of a Problem

Most projects are initiated because there is a problem that needs to be solved. It is important during project scoping to make sure that you really understand the problem that is to be addressed. This sounds very simple and sometimes it is. Sometimes the problem as stated by the project sponsor is exactly the problem that needs to be addressed. But sometimes the stated problem to be solved is not really the problem. There may be a deeper problem. In other cases, you are being asked to solve the wrong problem. The excellent BA will work to understand the true business problem before trying to solve it.

A technique used when trying to discover the source or reason for a problem is called root cause analysis. Root cause analysis involves identifying the known symptoms and looking for the cause of each symptom. Another technique, the five whys, is often used to organize and facilitate root cause analysis (see examples of the five whys in Chapter 7).

Case in Point

I was assigned to a project as the BA studying a specific cash management function. The project objective was to automate a manual transaction and decision with an online data entry screen and set of business rules. The underlying assumed reason for the project was to decrease costs by saving employee time. One subject matter expert, Frank, performed this work. He was an older man who had been doing this same work for many years. He primarily worked alone, and I had no reason to think that he was making mistakes or bad decisions. As I learned about his work, I began to wonder how much time automation would really save. He had a very efficient process. He also did not understand why the company was spending money to build this software. But we built it and implemented it. It wasn’t until a couple of months later when I heard an offhand comment from a corporate director that I learned the real reason for the project. Management was concerned that Frank was the only person who knew how to do this work and he was nearing retirement. Management wanted the process automated so that it was not dependent on one person’s knowledge. The concern was that Frank would never be willing to share his procedures or decision rationale. The true reason this project was funded was to avoid the risk of losing corporate knowledge as a result of a personnel change.