We started this topic (RFA vs RAD) with the observations that:
(1) Organizations, in their haste to deploy new or enhanced technology using rapid application development techniques, were taking significant risks that could be nearly eliminated by taking the time to develop and confirm requirements before coding; and
(2) Business process re-engineering sessions are a valuable way to flesh out requirements and maximize the return on investments in technology but that organizations are reluctant to use them because they take time and can lead to greater complexity and development costs. As one executive told me, “We don’t need staff input – we already know the best way to get the job done.”
I have to admit that the executive had a point. A few years ago, I walked into a conference room where a client had a group of staff members working on functional requirements. In their enthusiasm to flow chart a business process, they had covered the walls with flip chart paper and had filled virtually every sheet with “If” diamonds, connectors, and process blocks before getting deadlocked in heated debate. My heart sank. It wasn’t spaghetti code but it was certainly pretzel logic – there was no way to clearly identify the main path from the labyrinth of exception paths. We spent some time capturing the maze in Visio so that we could edit it, brought the team back in the next day and stepped them through each diagram. We stopped at each branch in the flow chart and asked the same questions:
(1) If we were starting from “scratch” would we do it this way?
(2) How often does this happen?
(3) How important is this functionality to meeting customer needs?
(4) Does this really need to be automated?
(5) Does this really need to be performed in different ways, or can a single process be adopted?
As you might expect, we began paring down the exception paths, and simplifying the process. By the end of the afternoon we had clearly defined the main path through the process and the most important branches. We had also identified several parts of the process that were presently manual and handled differently as well as some parts of the process that were solely related to limitations with their present information systems and could be readily eliminated. When we ran into debates about different ways to perform a part of the process, we backed them away from thinking about how they did it today and asked them to focus instead on how they would design the process if they were starting afresh. It wasn’t always easy, but the staff members got the hang of it quickly enough. As a result we were able to:
(1) Clearly define the automation boundary, including the functionality that was needed for the prototype and the functionality that could follow in later phases;
(2) Clearly define how the automated parts of the process would interface with the manual parts of the process (it is sometimes easier to empower employees to make decisions within specified bounds than it is to develop technology to handle every possible exception); and
(3) Eliminate a lot of complexity that added to cost without providing any real value.
Oh yeah, the staff members surprised all of us by becoming up with some insights and innovations that the executive team hadn’t thought about.
So, business process re-engineering sessions can be very useful. Just remember that the “main thing is keep the main thing the main thing.”
