A lot is written about methodologies, and I guess it's an area that is so informal, that everyone gets the right to use words as they please. In any case, I wouldn't presume to lay down rules for anyone by myself. That said, here's how I use the terms. First, imagine a continuum that runs from Algorithm, to Methodology and then on to Approach, as pictured in Figure 1.
Figure 1. A continuum of methods
At the left extreme we have algorithms — very precise ways to accomplish goals. In essence, conventional computer programs follow algorithms, do the same steps every time and always get the specified result. There are lots of things that business analysts do that involve following a precise set of steps — but they tend to be discrete, narrowly defined tasks.
You can't define a business process redesign methodology as an algorithm — there are simply too many steps, and too much depends on the specific circumstances of the particular project. (Each project is a separate case, to use the language of the Case Management folks.) A methodology defines a general approach, and usually includes branching points to accommodate the major varieties one might encounter. Thus, for example, in considering what to analyze, one needs a step that asks the redesign team to consider if the problem involves activity flow problems, problems with inconsistent results, employee performance problems, bad decisions being made, problems with supervision of employees, and so forth. Any given process might involve all of these, but most only involve a subset. Depending on the problems present in a specific situation, different analysis techniques are called for. They in turn will suggest different types of redesigns.
A methodology, like either Six Sigma or BPTrends Methodology has phases. Each phase is divided into steps. Each step specifies things to check, has decision points, and recommends diagrams to help clarify specific types or problems one might encounter. The methodology does not structure every step, but it certainly provides a very detailed structure to help the user.
At the right side of the figure I listed “approaches.” This refers to rather vague strategies for organizing the steps one might include in a methodology. The two most common approaches are the Waterfall approach, and the Agile approach. Waterfall suggests that you work through some set of phases, one after the other. Each phase is completed and signed-off before the next phase is initiated. The Agile approach, on the other hand suggests that you will commonly divide the problem into parts and complete one part at a time. In essence, you take small steps and complete one round of development and then go back and work on another round of development. Imagine, for example, that in the first phase you discover 4 problems with a process. You might then analyze, redesign and roll out the solution for one problem, check how it improves the process, and then return and tackle the second problem. You would repeat the process as many times as necessary to achieve your ultimate goal.
Obviously you could design a methodology around either approach. Most methodologies, like Lean, Six Sigma and BPTrends all rely on a combination of Agile and Waterfall. The choice largely depends on the complexity of the process problem being approached and the time and skill of the people involved. Those using a methodology like Six Sigma on small-scale projects where continuous improvement is the order of the day, are likely to lean strongly toward the agile approach. Those using a methodology like BPTrends when facing a major process redesign, are more likely to lean toward a mix with a good bit of the waterfall approach in it.
Another approach that you occasionally read about is often termed Outside-In. It simply refers to the fact that you began by determining what stakeholders need and then work into the process to assure that the process will serve the stakeholders. All methodologies do this these days, so it isn't saying much, but, its another good example of a strategy rather than a methodology.
The key thing to keep in mind is that these are different approaches that lie at different points on a continuum that ranges from the exact specification of steps, though methodologies that provide general directions, to approaches that amount to overall strategies. You would never want to try to compare Six Sigma and Agile, for example. They involve different types of goals and, in any case, are often combined. And the idea of agile algorithms should really be approached very carefully.
As I suggested earlier, different people use these terms in different ways. Underlying any given usage, however, are some concepts, like precise, and flexible, very generic, and specific steps, and we ought to try to respect those concepts in order to keep our language useful.
Speak Your Mind