Several years ago, my colleague, Cindy^[1] and I were facilitating sessions with a client, using the business rules approach.  There was a gentleman sitting at the back of the room throughout the sessions.  At the end of the day, he came up to us and introduced himself as the head of the IT department.  He said the approach was interesting, then added, "I just wanted to see if this was a perfect methodology."  Cindy and I looked at each other, and we burst out laughing.  We couldn't help it.  A "perfect" methodology?  There's no such thing!

Even though I'm a big proponent of methodology per se (and, especially, the business rules approach), I recognize that any methodology will have limitations.  There are a few characteristics that I feel are essential:

• The methodology must be built on a sound theoretical foundation.
• The methodology must be practical (i.e., it can actually be applied to real-world situations).
• The methodology must be adaptable.

Let's assume the first two characteristics are a given and focus on the adaptability.  There are two ways a methodology needs to be adaptable:

1. To your organization
2. To a specific project or change initiative

This month, I'll talk about adapting a methodology to your organization.

Adapting to Your Organization

It's always important to ensure that a methodology is going to fit into your environment.  Implementing a methodology is really a project or initiative in its own right and should be treated as a major change (with all the attendant change management issues).

Some areas to consider are:

• What kind of culture does your organization have?
  
  
• Does your staff have the appropriate skill sets?
  
  
• What communication needs to take place — not just with the staff doing the work but with all the various partners (business, IT, testers, etc.)?
  
  
• What training and mentoring is required, both initially and on an ongoing basis?
  
  
• Who are the champions that can lead the way in applying the methodology?
  
  
• Do you have the appropriate tools?
  
  
• What kind of projects should use the methodology?
  
  
• Do you have existing techniques that you need to change or replace?
  
  
• Are there existing methodologies with which you need to interface?
  
  
• Should the methodology be implemented all at once or should it be implemented in phases?
  
  
• How will the methodology be supported (e.g., through a center of excellence)?
  
  
• How will the methodology evolve?

Even the language used in the methodology needs to be examined.  For example, one of our clients loved our Policy Charter^[2] but, because they were an insurance company where the term 'policy' has a very precise meaning, they decided to call it a "Business Solution Strategy" instead.  This change helped the deliverable be more readily adopted.

Other organizations have used the Zachman Framework for Enterprise Architecture™ to help work out the techniques, deliverables, templates, and RACI^[3] for each cell in the framework.  This helped to ensure that all aspects of the business were addressed by the methodology.^[4]

Organizations that have successfully implemented the business rules approach also looked at how the methodology would be used in their environment — that is, from a process perspective:

• What tasks are needed to produce the deliverables?
• What controls need to be put in place (e.g., peer reviews, sign-offs, etc.)?
• Where are the hand-offs?
• What are the required roles and responsibilities?

It's a good idea to model the business analysis practice the same way as any business area — that is, to build a concept model (to address the terminology), a process model (to address how the work gets done), and a set of business rules (to provide guidance).^[5]

Conclusion

No matter how good a methodology looks on paper, careful consideration needs to be given to all these aspects when implementing it in your organization.

Even if you take the time to adapt it, the methodology still won't be "perfect" — but it will have a much better chance of being successful.

Next month, I'll talk about adapting the methodology for a given project or change initiative.

[1]  Many of my stories are Cindy's stories as well.  We have often been assigned together to support a client.  In fact, a number of our clients think of us as one person!  

[2]  Per Building Business Solutions:  Business Analysis with Business Rules, by Ronald G.  Ross with Gladys S.W.  Lam, a Policy Charter is "a deliverable in business analysis with business rules that lays-out the strategy for a business solution."  See References for articles on the topic.  

[3]  RACI = Responsible, Accountable, Consulted, and Informed.  It helps to identify the parties involved in a given deliverable or task.  

[4]  It always bears mentioning that the Zachman framework is not a methodology.  

[5]  As a side benefit, doing this gives the business analysts practice in the methodology.  

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

# # #