Dec
1
Investigating the Riva Process Methodology
December 1, 2006 |
Previously posted at the Requirements Networking Group.
The Riva Method, created by Martyn A. Ould, is a BPM methodology that makes a unique and compelling promise: that it can enable a business analyst to discover the full set of processes required by an organization in a matter of hours or days, and that the results are repeatable–that is, that two BAs using the method should come up with the same set of processes.
That’s one hell of a promise.
Why am I interested? Well, I’ve been through a number of process-oriented projects, and I’ve found over the years that defining what processes exist is very very hard. Put 5 SMEs in a room together and you usually wind up with 7 different lists of the processes found in an organization. Key processes are overlooked or neglected, while others which are supposedly rigidly defined turn out to be flexible.
The problem isn’t that I can’t come up with a process architecture. I’ve been doing it for some time and while I don’t claim to be perfect at it, I can usually get results I’m comfotable with. The problem is that another BA can go into the same area and see a different set of processes, and we end up spending a lot of time trying to get everyone to agree on what the business looks like (I’m normally right, of course ;-)).
This is particularly a problem right now, as the project I’m on involves developing a system that allows our clients to execute and manage their processes. Because I did most of the requirements for the system, I can naturally think about a described process in terms that easily fit the application. The business people, and the BAs who don’t have the model ingrained in their heads, can’t do so as easily. What I need is a method I can teach them that will get them to think about what’s really going on in the business, and then map that understanding into our application.
Riva claims to be able to turn process development from an art–one dependent on the judgment of the individual BA–into a craft that can be taught and perfected. If it can do that I’m definitely interested.
Riva works on the following principles:
- A process is an interaction between people and groups in order to accomplish a goal.
- It can be thought of as transforming a work item from some initial state into a final state that fulfills some need.
- Processes come in three levels: the ones that work on individual work items, the process to manage the progress of all similar work items, and the process to evaluate the effectiveness of the lower-level processes.
- Given an understanding of the work items an organization deals with, then, as well as the relationships between them, you can derive all the processes that must exist.
That’s a very high-level overview, of course. Is it pure craft? Well, no, I don’t think it is. There’s art in generating the list of work items, and in figuring out exactly how each process works, but it seems to systematize that work more than most of the alternative approaches, which hand you a diagramming notation and tell you to go map. Even if Riva only delivers 75% of its promises, though, it would do a lot to make process analysis more accessible and enable junior to intermediate BAs to be successful with it.
I’m not, however, going to review the book in the usual fashion. No matter how good it sounds, the effectiveness of the method can only be judged by seeing if it helps me with actual process definitions. So that’s what I’m going to be doing. I’ll let you know if it works, where the challenges lie, and in the end whether I found Riva useful enough to start training the BAs I work with how to use it.
Comments
1 Comment so far
What I'm Reading- Do You really Believe in What you Do?Requirements Defined - Seilevel's Software Requirements Blog
- C.R.A.C.K. Requirements managersBetter Projects
- ‘IT has no inherent value’IT Project Failures
- Business Analysis in an Uncertain EconomyJonathan Babcock
- Why We Lost Focus on Development PracticesAgile Management Blog
- Talking about what we doRequirements Defined - Seilevel's Software Requirements Blog
- BPM is not Software EngineeringGo Flow
- 3 Big CaliberRM Gotchas And How To Fix Them Part 1Requirements Defined - Seilevel's Software Requirements Blog
- Project World and World Congress of Business Analysts (PW&WCBA)Better Projects
- Troubled ProjectsHerding Cats
Oooh. Paint by numbers requirements. Really interested to see how it goes. And if there’s room on the end of the scale, add me to the “slightly more skeptical than you” camp.
Good luck and keep us posted!