#13-Assess the Business Process Impact of New Projects

When creating something new of value, one must always consider the context within which it will operate.  Part of this is determining what, if anything, in the existing business processes will be effected by the new work.  Failing to take this into account can have serious consequences, as this episode will demonstrate.

Transcript

Assess the Business Process Impact of New Projects

It's not enough to understand the work that needs to be done. You must also place that work in the context of existing business processes so you can identify potential impacts that may not be anticipated in the requirements.

Here is an example: several years ago, a bank in my home state of Washington had a new product that they wanted to roll out, namely a service to allow a customer to deposit a check using the camera on their smart phone. This was in response to a new market opportunity that arose from the ubiquitous popularity of these phones and their high-resolution cameras.  At the time it was considered an innovative idea.

The bank had an existing ability for depositing checks of course.  Entities were identified such as the writer and receiver, and the banks involved, plus the accounts effected. All this was done in a series of "use cases" which was very typical at the time. What they did not do was identify and model the business process itself.

That process/workflow was in the minds of different people, but not clearly delineated anywhere.  It was: 

Check is written -> Check is received -> Check is signed and brought to the bank/ATM -> Funds are confirmed -> Accounts are credited/debited accordingly -> Check is put into storage.

Essentially the idea was to replace one step, namely "Check is signed and brought to the bank/ATM" with an alternative path: "Check is photographed and an image is uploaded to a web service". There was a lot to do to build that service, including an end-user website, various pieces of management software, and a lot of back-end work in the databases and server farm.

What was not adequately considered was how this new feature would impact that existing business process, which was the context for the work. They had no practice in place to reveal this and so a major aspect was missed; one which, had they not stumbled across it, could have resulted in massive financial and legal problems.

When you deposit a check at the bank either though the teller or at the ATM and the financial transfer goes through one more thing happens. The physical check is stored for seven years. This is done to allow them to resolve any future disputes by anyone involved in the transaction. Was the check fraudulent? Was it altered? Was it cashed by the wrong person?  Etc...

When a photo of the check was sent there would be no physical check to store. Were there to be a dispute someone would have to pay and that someone would be the bank itself because, as the lawyers eventually told them, a photograph is not considered a legal document.

Immediately they had to rethink the entire project. Should they have their depositors send in the checks later?  Where to, and how?  Should the branches have drop boxes? Should their lobbyists try to change the laws regarding photographed checks?  A lot of solutions were proposed, most of them quite expensive.  At the end of the day, they decided to limit the size of checks that can be deposited by photograph as it was determined to be cheaper to eat a few small checks that it would be to create an entirely new infrastructure.

Part of the collaborative process of writing acceptance tests includes identifying all the stakeholders, the context of the business process, and all dependencies to it. Had they done ATDD they would have identified this "storage" problem far earlier and a lot of waste would have been avoided. As it was, they simply got lucky.

Learn how do ATDD, and make sure every stakeholder participates in it. It's not hard to learn, it's not hard to do, but it can save you from disastrous mistakes.