Last month^[1] 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:

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

2. 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.^[2]

3. The level of detail required for each deliverable

It is not always necessary to thoroughly detail every aspect of the business area being analyzed.^[3]  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.

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

5. 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^[4] 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.

6. 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.^[5]

Conclusion

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.

[1]  Kristen Seer, "The Perfect Methodology (Part 1)," Business Rules Journal, Vol. 14, No. 12 (Dec. 2013), URL:  http://www.BRCommunity.com/a2013/b731.html  

[2]  This assumes that you have a business architecture in place or some form of governance for your business rules.  

[3]  This is where some business analysts have difficulty — they want their analysis to be "perfect" and spend too much time on areas that don't contribute to the business solutions.  

[4]  It's surprisingly difficult to not be rigorous once you've gotten used to writing business rules using techniques such as RuleSpeak™!  

[5]  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.  

References

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

# # #