IDC Blog

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.”

We’ve all heard the old joke about “Ready, Fire, Aim” but for many execs in government and business that we speak with, and who are being pressed to quickly respond to mission-critical operational requirements or competitive pressures, it’s not so funny. “Agility” has become the standard by which the effectiveness of executives and organizations is measured. To be agile, you need to be nimble and fast, but to be agile AND effective you also need to be right. Too often though, in the race to be agile, the delivered systems miss the mark. Sometimes, if the miss is not far of the mark, you can quickly recover; but mostly we see a lot of scrambling to get a temporary fix in place to buy some time. For our first few posts in the Blog, I’d like to share some thoughts with you about steps that can be taken to ensure success while avoiding the pitfall of “paralysis by analysis.”

I’ve always felt that business process re-engineering (BPR) sessions provide an invaluable opportunity to ensure that you’re automating the right stuff and getting the most value from the technology investment; but many execs are wary of conducting BPR sessions as part of the IT development process. They fear, and rightly, that BPR sessions can take too much time and encourage the development and inclusion of requirements that add complexity, risk, and cost, without a lot of value. BPR just doesn’t seem to fit in with the concept of “agile.”

But it doesn’t need to be that way. You can get the benefits of BPR while being agile – in fact, BPR may actually be one of the best tools available to enable you to quickly focus on the most important requirements, to validate the system approach, manage risk, and ensure that the delivered system provides maximum impact. But you have to plan to make this happen. As the late Ozzie Davis wrote, “It’s not the rap; it’s the map,” and our map, and the subject of a series of blog posts over the next few blog entries, will include some thoughts on: a) getting stakeholder buy-in and commitment, b) re-structuring the review of your “As Is” business processes or technology environment to focus on high-value activities, c) developing a blueprint for your “To Be” environment in stages, and d) rethinking how we put together and execute a transition plan.

IDC Completes LA County Disposal Facility Tax Audit