You have just been assigned to a project as a business analyst.^[1]  It may be your first time on a project, it may be the first project to use the business rules approach, or it may be that the project team members have never heard of business rules.  Regardless of the scenario, there will be numerous challenges for you to face during the course of your assignment.

This article explores ways for you to meet those challenges.  It presents a series of ideas to help you be more effective throughout your assignment.  It covers:

• First things first -- laying the groundwork for the future
• A clear path -- keeping your destination in mind
• The lay of the land -- assessing the current business situation
• In session -- gathering the business rules
• Heads-down analysis -- making sense of what you've gathered
• Sign-offs and hand-offs -- producing the deliverables

This article assumes that you will be responsible for conducting business analysis -- using the business rules approach -- during the analysis phase of a project.  You will gather business requirements using interviews and/or facilitated sessions.  The results of your analysis will be documented in the form of one or more deliverables, sometimes referred to as a 'business model.'  The deliverables may consist of workflow, some form of glossary with terms and definitions, and business rules.  The specific deliverables will depend on your organization and the needs of the project.

Much of this article offers insights that fall under the heading of 'common sense' and may seem self-evident to experienced business analysts.  Many of the recommendations are good rules of thumb for any role on a project, not just business analyst.  This is because, in the end, success on a project often depends on basic things like communication, trust, and consideration for others.

Throughout the article, there are tips that will help keep things running smoothly.  These are outlined in boxes.

First Things First

Meeting with the Project Manager

The first thing you should do is meet with the project manager (PM).  This meeting marks the beginning of a crucial relationship; it can set the tone for your entire assignment.  A successful working relationship is built on trust.  Properly handled, this meeting can go a long way towards establishing that trust.

Your objectives for this meeting are to clarify your role on the project and to get an understanding of the project manager's expectations.

Project managers have different styles and backgrounds, so it is important to understand how they operate.  Here are four questions for you to consider:

1. Are they hands-on or laissez-faire?
   Do they like to be involved in all aspects of the project, such as detailed planning and sitting in on meetings, or do they prefer that you handle everything yourself?
   
   
2. Are they detail oriented or 'big picture' oriented?
   Some PMs draw up very detailed project plans, while others prefer to set an overall framework and let the team fill in the details.
   
   
3. Do they know about the business rules approach?
   Be prepared to spend some time explaining the approach and its benefits.  Frame the benefits in terms that have meaning to the PM, such as saving time and money, decreasing the risk of missing business requirements, etc.^[2]
   
   
4. How much do they like to be kept 'in the loop'?
   Some PMs want to know everything that's going on, while others only want to see you when you've completed a major task or need help to resolve an issue.

Understanding your project manager's style and background enables you to manage the relationship more effectively by tailoring your communications to their needs.

In this initial meeting, you need to gain an understanding of the project:

• What are the scope and objectives?
• What are the key business drivers?
• How much business support is there?
• What are the major issues?
• Is there documentation to review?
• Who are the key players?
• Who is on the project team?

This information should give you a clear picture of the project and where you will need to focus your energies (e.g. building support for the business rules approach, resolving major business issues, building consensus on a solution, etc.).

A project manager's job is a difficult one.  The more you can find ways to help them, the more likely they are to help you in return.  For example, you might volunteer to help put together the project charter.  You can ensure that the business scope is clearly defined and a description of the business rules approach is included.

Project managers tend to structure their projects in a certain way and it is useful to know how they like to proceed:

• How and how often do they like to get status reports?
• Are there team meetings that you need to attend?
• How are issues managed?  Is there a form that needs to be used?
• What is the process for escalating issues?
• Can you interact directly with the project sponsor, or do you have to go through the PM?
• Do they want to sit in on any facilitated sessions and/or interviews?

You should discuss, in general terms, the process for gathering business rules and the types of deliverables you can produce.  At this point, you should not commit to anything, just outline what you might do (given what you know of the project so far).

By the end of the meeting, you should have a clear understanding of the project and the PM's expectations.  The project manager should have a clear understanding of your role and an overview of the business rules approach.

A project manager is always trying to balance time, resources, and scope.  There is often more pressure on one than the other.  For example, the final deadline might be immoveable, but there may be room for additional resources.  It can be helpful to understand these pressures so you know how much room the PM has to move if you need more time, resources, or an increase in scope.

Getting the Corporate Perspective

Once you've met with the project manager, the next step is to find the 'mapmakers.'  These are the individuals or groups that have gone over the same territory that you need to cover.  You may or may not have the following departments or functions in your organization, but if you do, I recommend that you pay them a visit.  They can save you much time and effort.

These groups usually offer one or more 'methodologies' for you to follow.  The methodology may have been developed in-house, or it may have been purchased from a vendor.^[3]

A project management office or a methodology group can provide:

• Templates for the deliverables
• Analysis techniques (e.g. workflow analysis, rule decomposition, etc.)
• Tools to help document the deliverables (e.g. Visio, RuleTrack™, etc.)
• Checklists of things that need to be done

A corporate architecture group can identify:

• Existing business models of the area you are investigating
• Other projects that are focused on the same business area
• Corporate standards that need to be followed

A rule management group can provide:

• Existing business rules
• Guidelines/templates for expressing the rules

Taking advantage of these groups prevents you from having to forge a new trail -- you can simply follow the path they've laid out.

Meeting Your Team Members

At this point, you'll want to have introductory meetings with the team members.  It's a good idea to find out what the team knows about the business rules approach.  You may need to spend some time getting them on board.  This could include informal chats with individual team members or a more formal presentation for the entire group.  The more the team understands the approach, the easier your life will be.

Another important meeting at this stage is with the project sponsor.  You will likely have to explain the business rules approach -- at a high level -- so that the sponsor understands the importance of having the right resources participate in the business analysis.  Let the sponsor know that you may be calling on them to help resolve business issues and/or provide support if there are any problems with the level of participation.

By now, everyone should know who you are and what you will be contributing to the project.  It's time to get the route mapped out for your analysis.

A Clear Path

With a good understanding of the project and its players, you can map out how you plan to proceed.  There are numerous factors to consider in selecting the best 'route' through the analysis:

1. Facilitated sessions vs. interviews
   This isn't really an either/or choice as you may elect to use both techniques.  Interviews are often useful to gather preliminary information.  Facilitated sessions are the most effective way to gather business rules, particularly where there are a number of departments involved or when there is a need to build a consensus.
   
   
2. Focus on 'as is' vs. 'to be'
   There is never enough time on a project to fully analyze both the current picture ('as is') and the future vision ('to be').  It is a good idea to decide up-front where you need to spend your time.  This will depend on the objectives of the project.  If, for example, the objective is to radically re-engineer the business, there is no point in spending a lot of time on the 'as is' picture; the focus should be on building a thorough 'to be' solution.  If, however, the objective of the project is to move from one technology platform to another without changing the business, the focus should be on the 'as is' situation.
   
   
3. Focus on rules, terminology or workflow
   Because rules don't exist in a vacuum, your analysis will likely encompass other aspects of the business such as the terminology used in the rules and the workflow where the rules are applied.  However, most projects tend to impact one aspect more than the others.  For example, if the business concepts are changing dramatically, you'll want to spend more time on terminology and ensuring that terms are well defined.  If the workflow is being completely reengineered, you'll want to focus on that.  If the rules are changing significantly (e.g. due to legislative changes), then the focus should be on the rules.
   
   
4. Implementation approach
   You need to understand what will happen after you complete your analysis.  Will the business requirements be used to help select a software package?  Will they be used to implement business change (e.g. reengineering)?  Will the rules be implemented in a rule engine?  The answers to these questions will help determine the level of detail and rigor required.
   
   
5. Level of participation
   It is critical to ensure that you get the right level of participation.  This means both getting the best people and having them available when you need them.  If there are scheduling, political, or personality issues, you need to be aware of these so that you can factor them into your approach.
   
   
6. Inter-project dependencies
   If there are other projects that will affect the same business area, you need to coordinate with them so that you are not at cross purposes, particularly with respect to scheduling the participants' time.  Also, you may be able to re-use some of their work (and vice versa), thereby ensuring consistency as well as reducing the time needed to gather the requirements.

Deciding up-front how you will handle these factors will help ensure that you focus your time and effort in the right places and that you don't miss anything along the way.

Now that you have considered all the factors that might impact your analysis, you can determine the best route to take.  You need to decide:

1. Which deliverables to produce
   This includes not only the specific deliverables required, but the format, content, and level of detail in each.  If there are templates available, you can modify them as required; otherwise, you'll have to build your own.  It's a good idea to do this up-front rather than waiting until you need to produce the deliverables, as it helps you think about what information you need to gather during the course of your analysis.
   
   
2. Who the audience is for the deliverable
   This includes who needs to sign off on the deliverables as well as who will use them and for what purpose.
   
   
3. How to gather the requirements
   If you've chosen to do preliminary interviews, decide with whom you will do them and how long they should be.  Also, determine how you are going to document the results of the interview.  For facilitated sessions, decide how many sessions you will need and who should participate.
   
   
4. How to manage the rules
   This may need to be within a framework set by the rule management group. The process needs to include:
   
   
   • how to express the rules in a consistent manner (e.g. using templates such as RuleSpeak™)
     
     
   • how formal the rules need to be (e.g. the rules need to be very formal if they will be implemented in a rule engine, but less precision is required if they will be used in a policy manual)
     
     
   • how to resolve conflicts in the rules
     
     
   • what information needs to be kept about each rule, such as:
     
     
     • status (e.g. pending, approved, retired, etc.)
       
       
     • jurisdiction (i.e. whether the rule applies corporate-wide or only to a specific business area)
       
       
     • reference source (i.e. where the rule originates, such as legislation, a policy manual, etc.)
       
       
     • enforcement level (e.g. strictly enforced, overrides allowed, etc.)
       
       
     • relationships between rules (e.g. supports, conflicts with, replaces, etc.)
       
       
5. How to keep everyone informed
   This is essentially a communication plan so that you can ensure smooth communication with the business participants, amongst the team members, and with your counterparts on inter-dependent projects.  Constant communication is critical, and you need to factor it in, as it will cause innumerable problems if you do not.

Mapping out a well-defined approach helps to keep you on track throughout the project.  It also helps to avoid re-work because you know up-front what information you need to gather.

Now you're ready to put together a plan for the analysis phase.  If the project manager has already created a detailed plan, you should review it to ensure that it covers all the necessary tasks, and allows sufficient time to gather, analyze, and document the requirements.

If the project manager has done only a high-level plan, you will need to work within the boundaries laid out in the plan and flesh it out with greater detail.  Ensure that all the tasks are identified with a reasonable estimate as to their effort and duration.

If you've never put a plan together before, ask your project manager for help.  Break the tasks down into manageable chunks that are of one to two weeks' duration.  If there is a fixed deadline, you can work backward from it, adjusting tasks as required to fit into the allotted time.

Once you've formulated your approach and drafted the plan, you should review them with the project manager.  You may need to ask for additional time and/or resources at this point.  This is where an understanding of the pressures on the project manager comes into play.  Also, the PM needs to see that you can justify the extra time/resources.  A well-thought-out plan is the most effective form of justification.  Be prepared to negotiate.  The scope may need to be reduced if there is no room to move on time and/or resources, so have some suggestions at hand.

Once the project manager has approved your approach and plan, you should discuss the relevant parts with the project team so they know when to expect the deliverables.  Some of the team members may want to sit in on the facilitated sessions, so they will need the schedule.  You might also want to show them the templates for the deliverables, so they will know what to expect.  Make sure they understand exactly what it is you are going to deliver.

This preparation phase lays the groundwork for the rest of the project.  Thinking things through up-front will save you considerable time and effort later.  You now have a clear path to follow during the course of your analysis.

The Lay of the Land

You can now start your analysis of the current ('as is') situation.  To gather information for this stage, you can use the following sources:

• Legislation
• Policy manuals
• Procedure manuals
• Computer systems
• Site visits
• Subject matter experts
• Manager and/or staff interviews
• Internal and external websites

From these sources, you can draft an initial business model that you can use as a starting point in the facilitated sessions.  How much time you spend on the 'as is' picture will depend on the decisions you made in the preparation phase.  It is easy to get bogged down at this point, so it is helpful to have those decisions to prevent you from spending too much time.

Even if the focus is on the 'to be' vision, it is useful to spend just enough time on the 'as is' picture to identify the problem areas.  This will enable you to ask the right questions in the facilitated sessions and to ensure that the solution that the participants devise will address the current problems.

In Session

The time has come to gather the business rules in facilitated sessions.

One of the critical success factors in gathering business rules is to have the right people involved in the sessions.  These people are usually very busy, so it can be difficult to get them to attend.

For each session, identify the critical participants and work around their schedules, giving them as much advance notice as possible.  It is sometimes helpful to meet with them briefly to ensure they understand why their participation is so important.

If the participants are not familiar with the business rules approach, you may want to do a brief presentation in the first session to provide an overview.

Once you are in the facilitated sessions, all the usual good facilitation practices apply -- having a clear agenda, making sure everyone participates, having an experienced scribe, etc.  As there are numerous articles and books on facilitation, I won't deal with the topic here.

If you are drafting business rules or definitions of terms in the session, don't spend time on wordsmithing.  For rules, follow the template as much as you can in the first cut, but don't spend time getting it exactly right.  For terms, get the gist of the definition and move on.

Keep a flip chart listing any issues that cannot be resolved in the session.  This 'parking lot' can help the group avoid getting stuck on a given issue.  Make sure that, by the end of the sessions, you have a person assigned to follow up on each issue.

It always helps to create a pleasant environment for your sessions.  If you have the budget for it, treats such as cookies, muffins, or doughnuts are always welcome.  Icebreakers like Play-Doh™ or LEGO® can help loosen up the group (and, for those used to sitting in front of a computer all day, keep their hands busy).

Allow yourself enough time between sessions to document the results of the session, follow up on issues, and prepare for the next session.  You really need this time to keep on top of all the information gathered in the sessions; otherwise, you risk losing some of it.

In the last session, let the participants know what you will be doing over the next few weeks to produce the deliverables.  You may want to ask the group to designate a single contact to handle any questions you might have and/or to follow up on any outstanding issues.  Also, let them know that you will need to get them together for a final session to review the deliverables.

Heads-down Analysis

Once you've completed the facilitated sessions, the next step is to verify the rules.^[4]  This involves:

• making sure each rule is expressed correctly.  The rules should adhere to the template or syntax established during the preparation phase.
  
  
• checking for conflicts in the rules.  The rules shouldn't contradict each other.
  
  
• checking for redundancy in the rules.  The rules shouldn't overlap or be duplicates.
  
  
• ensuring that the terminology is consistent.  Every term used in a rule should have a definition in the glossary.
  
  
• ensuring that you are not using synonyms.  The same term should be used consistently throughout the rules.
  
  
• mapping the rules to the tasks in the workflow.  Every rule should map to at least one task.
  
  
• decomposing the rules to the 'atomic' level.^[5]  The degree to which you do this depends on the level of formality that you identified during the preparation phase.
  
  
• ensuring that the information you've gathered for each rule (e.g. status, reference source) is complete.

Ensure that the issues identified during the facilitated sessions are resolved and incorporated into the documentation.

Throughout this phase, you should be in constant contact with the business participants (or their designated contact) to review any changes that you need to make to the business model.

Sign-offs and Hand-offs

During and after the facilitated sessions, you should be generating the deliverables by filling in the templates you set up in the preparation phase.  By now, the deliverables should be almost complete.

Before finalizing the deliverables, you should do a walkthrough with the session participants to validate^[6] the business model.  Be sure to distribute the material well ahead of time; however, do not expect that everyone will actually read it -- people rarely have time to go through that much information.

During the walkthrough, highlight any changes that have occurred to the business model as a result of your heads-down analysis or the resolution of any issues.

Expect some changes to the deliverables as this will be the first time that everyone is able to see the complete picture.  Make sure you allow enough time after the walkthrough to incorporate the changes.  You may need a second walkthrough if the changes are extensive.

Once the participants are happy with the deliverables, you may want to do walkthroughs with your team members and the architecture/rule management group.  This approach is generally more productive than simply handing off the deliverables as it gives people a chance to ask questions.  It also gives you the opportunity to highlight any contentious areas and to provide the rationale behind key business decisions.

Once everyone is satisfied with the deliverables, it is time to get the appropriate sign-offs from the people you identified during the preparation phase.  It is a good idea to notify people that you will be sending them the deliverables and will need their signature within a certain timeframe.  You may want to meet with key individuals to give them an overview of the deliverables, particularly if they were not involved in the facilitated sessions.

Throughout the project, keep in contact with the project manager using regular status reports and informal updates (how and to what extent you do this will depend on what you learned in your initial meeting).  The PM should be apprised of any issues that could 'blow up' or require their assistance.  Also, let the team members know of any changes to the plan.

Conclusion

Because the business rules approach is relatively new, you will likely find yourself acting as an 'ambassador.'  This involves not only 'selling' the approach to each new group of people but also guiding them through the process of gathering the business rules.  You will gain greater participation and support by doing this.

The old Boy Scout motto "Be Prepared" certainly applies to any assignment as a business analyst.  The more preparation you do, the more time and effort you will save as you progress through the project.

Establishing and maintaining a good working relationship with the project manager, your team members, and the business participants will ensure that your assignment progresses smoothly.

The ideas presented in this article may not guarantee success on a project, but they will definitely make your journey easier.

References

[1]  In his latest book, Principles of the Business Rules Approach, Ron Ross highlights the importance of the business analyst role, stating, "The key role in solution development for the 21st-century business is that of business analyst." 

[2]  See Ron Ross's article in the March 2003 edition of the Business Rules Journal for a list of the problems addressed by the business rules approach. 

[3]  A good example of a business rule methodology that can be purchased is Proteus™, developed by Business Rule Solutions.  For more information on the methodology, please refer to www.BRSolutions.com. 

[4]  I am using the term 'verify' to mean ensuring that "business rules are expressed in the right way" as per Dr. Silvie Spreeuwenberg's definition in her article "Using Verification and Validation Techniques for High-Quality Business Rules." 

[5]  According to Barbara von Halle in her book Business Rules Applied, 'atomic' means "each rule must represent one thought such that you cannot decompose it and still have it guide the behavior of an actor." 

[6]  I am using the term 'validate' to mean that the business rules "express what the business wants to express" as per Dr. Silvie Spreeuwenberg's definition in her article "Using Verification and Validation Techniques for High-Quality Business Rules." 

Bibliography

• Ronald G. Ross, Principles of the Business Rules Approach, Addison-Wesley, 2003.
  
  
• Ronald G. Ross, "Business Problems Addressed by the Business Rule Approach," Business Rules Journal , Vol. 4, No. 3, (March 2003), URL: http://www.BRCommunity.com/a2003/b123.html
  
  
• Dr. Silvie Spreeuwenberg, "Using Verification and Validation Techniques for High-quality Business Rules," Business Rules Journal, Vol. 4, No. 2, (February 2003), URL: http://www.BRCommunity.com/a2003/b132.html
  
  
• Barbara Von Halle, Business Rules Applied: Building Better Systems Using the Business Rules Approach, John Wiley & Sons, Inc., 2002.

Proteus, RuleTrack, and RuleSpeak are registered trademarks of Business Rule Solutions LLC. Please see www.BRSolutions.com for more information.

# # #