The Perfect Methodology (Part 2)
Last month I talked about the futility of expecting a methodology to be "perfect" and how adapting a methodology to your organization is critical for success. This month's article is about adapting the methodology to a specific project or change initiative.
Adapting to a Project or Change Initiative
Like any methodology, a business rule methodology comes with a diverse set of methods, techniques, deliverables, etc. For each project, it's important to determine which techniques and deliverables are appropriate to the business problem at hand.
Some things to consider are:
- What is the scope and size of the project?
- Are the business goals clearly defined?
- Is the project introducing new products or business lines?
- Is the business vocabulary well-understood?
- Are there major business process changes?
- Is it a rule-intensive project?
- Is the change focused around operational decisions?
- Is the analysis focused on the business 'as is' or on the 'to be'?
- Is the analysis supporting in-house system implementation or purchasing a software package?
As every analyst knows, there is never enough time allocated to business analysis on projects, so it is critical to ensure that the analysis stays focused on the right things. Upfront planning should identify how the methodology will be tailored to the business problem.
There are a number of factors to consider:
- Which deliverables should be produced
It isn't always necessary to produce all the deliverables in a methodology — although I do find that you usually need to address the triumvirate of business vocabulary, business process, and business rules to some degree on almost every project.
- What information should be captured for each deliverable
This usually includes the properties (e.g., status, reference source) that you will need in order to manage the results of the analysis, both for the duration of the project and for the longer term as part of the business architecture or "blueprint" of the organization.
- The level of detail required for each deliverable
It is not always necessary to thoroughly detail every aspect of the business area being analyzed. Sometimes it is sufficient just to get a broad overview. For example, if the focus is on the business rules required to support an operational decision, it might be sufficient to map out the process just enough to understand where the operational decision fits into the overall scheme of things. Again, it's important to know where to focus your efforts.
- Whether the focus is on 'as is', 'to be', or both
If you are looking for incremental improvement in a business process, then mapping out the 'as is' processes is important to understanding where the problems are. However, if the objective is to completely re-engineer the process, then you want to spend the bulk of your time on the 'to be' perspective. For the business rules, you might want to focus only on those rules that you know are changing. Remember, it's not about documenting the existing problems; it's about finding a solution.
- The degree of rigor required for the deliverables
Although in an ideal world, you want to express your business rules as rigorously as possible using best practices such as RuleSpeak™ and consistent vocabulary, there are times when that is not necessary. For example, one of our clients wanted us to rewrite the business rules in a procedure manual to make them easier for staff to understand. Although we tried really hard to be rigorous it wasn't what the client wanted. Nor were they ready for adopting a full business rules approach. We ended up with rules that were non-atomic (in some cases, whole paragraphs!) but using consistent, well-defined vocabulary. What we delivered took them a step closer to managing their business rules and it met their immediate needs.
- What techniques will be used to capture the information (e.g., interviews, facilitated sessions, harvesting from documentation, etc.)
Once you decide what it is you need to capture and analyze, then you can decide how to capture it. For example, if you need to harvest a set of complicated rules that only one or two people in the organization understand, you might want to use interviews, or perhaps harvest the rules from existing documentation and then review it with the key subject matter experts.
All the techniques and deliverables in a methodology are simply tools in your analysis tool kit. Each tool has a specific purpose. You need to determine which are the best tools to help you craft a viable business solution for the problem at hand.
There is no "perfect" methodology that you can fully apply to every situation. You have to make it work, both within your organization and on each project or business initiative.Notes
 Kristen Seer, "The Perfect Methodology (Part 1)," Business Rules Journal, Vol. 14, No. 12 (Dec. 2013), URL: http://www.BRCommunity.com/a2013/b731.html
 You also need to consider the who at this point — who needs to be involved as subject matter experts, reviewers, (etc.), and what business areas need to be represented. And, to complete the picture, the when. This is all part of the upfront planning but is outside the scope of this article.
Building Business Solutions: Business Analysis with Business Rules by Ronald G. Ross with Gladys S.W. Lam (2011, An IIBA® Sponsored Handbook). URL: http://www.brsolutions.com/bbs
Business Rule Concepts: Getting to the Point of Knowledge (4th edition, 2013) by Ronald G. Ross, http://www.brsolutions.com/b_concepts.php
Gladys S.W. Lam, "Business Knowledge — Packaged in a Policy Charter: Policy Charter as a Deliverable," DataToKnowledge Newsletter, Vol. 26, No. 3 (May/June 1998). URL: http://www.BRCommunity.com/a1998/a385.html
Gladys S.W. Lam, "Estimating the Time Required for Business Rules Harvesting — Part 1: Ask These 13 Questions," Business Rules Journal, Vol. 14, No. 1 (Jan. 2013), URL: http://www.BRCommunity.com/a2013/b683.html
Ronald G. Ross , "What Are Fact Models and Why Do You Need Them (Part 1)," Business Rules Journal, Vol. 1, No. 5 (May 2000), URL: http://www.BRCommunity.com/a2000/b008a.html
John Zachman's Concise Definition of The Zachman Framework™ by John A. Zachman (2008), www.zachman.com
# # #