Standards

Setting standard analysis techniques and deliverables is difficult. Projects vary greatly, and the analysis necessary differs in quantity, perspective, and level of detail. Organizations should be careful when setting business analysis standards. Requiring a particular requirement deliverable for every project seems like a good way to introduce consistency into requirements but may result in wasted work for projects for which the technique is not appropriate. New BAs need guidance when choosing techniques. Ideally, this guidance is provided by a mentor rather than a set of standards. There is a benefit in trying to use the same set of presentation formats (e.g., decomposition diagram, ERD) on most projects because stakeholders will become accustomed to them and become efficient at reviews.

Case in Point

One organization with which I was doing some consulting work had a standard list of required requirements deliverables. The BAs were complaining because the time required to prepare these deliverables slowed down their projects and they felt many of the deliverables were a waste of time. I was asked to review the list and give my opinion. I was surprised to see two diagrams right at the top of the list which are both used to show the scope of an analysis area: the context-level DFD and the IDEF0 context diagram. These two analysis techniques are very similar, but they were developed from two different software development approaches. They are both excellent techniques, but my question was “Why do both?” The answer was that the manager who had developed the list preferred the IDEF technique (she had used it successfully at another company), while other analysts were familiar and successful with the context-level DFD. So they were both included!

My recommendation was simple: require one of the two diagrams but not both. Allow the analyst to choose the appropriate technique for each project. My recommendation was not immediately accepted. Management’s concern was that the analysts would not know which diagram to use. Flexibility in standards requires the BA to understand the differences in the techniques and make intelligent decisions about which one to use. Experienced BAs must be given flexibility to choose requirements deliverables that clearly communicate specific project needs. Newer BAs should discuss deliverable selection with their mentor or manager. Having a rule that requires the same deliverable to be used for every project creates unnecessary deliverables and wastes valuable time.

Tables 6.7 and 6.8 show examples of guidelines for deliverables for different types of projects and different audiences, respectively.

As is vs. To be analysis

When eliciting, analyzing, and documenting requirements, the BA must always be aware of the state of the business environment he or she is capturing. There are two states: the current state of the business, commonly referred to as the as is, and a potential future state of the business, commonly referred to as the to be. It is very easy to forget about this difference and allow requirements to include both in a confusing mix in a single diagram. This is an easy mistake because when business stakeholders talk about their work, they will often tell you (1) what they currently do, (2) why they see a need for a change, and (3) their recommendation for a change. An experienced BA listens carefully for these three very different pieces of information and dissects them into their components. For example:

I log in to our accounts receivable system to enter the customer purchase information and make sure that the information is correct. Then I have to log in to our customer relationship management (CRM) system to enter the customer profile. This is a waste of time because I have already entered the address into accounts receivable (AR) and I have to type it again. The AR system should send this information to the CRM system to save me time.

Table 6.7: Deliverables to Project Matrix

Table 6.8: Deliverables to Audience Matrix

The BA must be careful to listen for the facts vs. opinions or ideas in this discussion. The current process (as is) was described briefly, but the speaker got distracted by describing his or her problem and recommendation. Did the BA get a clear, complete description of the current state? No. The BA needs to ask more detailed follow-up questions:

• What specific data items are entered in AR to process the payment?

• How is the information validated?

• What if the payment information is not correct or is incomplete?

• Is the CRM system still updated?

• What specific information is entered into the CRM system?

• How many fields are entered into both systems?

• Are the fields named the same?

• Why does the procedure require this double entry?

• What if this customer is already in the CRM system?

• Is the profile updated?

Business analysis professionals must be very careful not to jump to conclusions or recommendations without understanding the as is state. If solutions to business problems were extremely obvious, they probably would have already been implemented. An analyst wouldn’t be needed in such situations. Rarely are good-quality solutions that obvious or simple. There are a whole complex set of parameters that impact the problem and situation, and all must be considered before a solution is proposed.

Do you need to document every detail of the current state when you know that it is going to change? This is a judgment call that the BA and team must make. The current state needs to be understood and considered carefully, but it does not always benefit the team to create detailed, presentation-quality documents that describe it (see the discussion in Chapter 4 on learning the current system).

Every project and situation within a project must be evaluated individually. Depending on the reason for a project, the BA will determine the type of documentation that is appropriate. Returning to the AR example, why are you learning about the as is procedure? Is the goal to document the current procedure because new employees will be hired and must learn this job? Has the BA been asked to look for possible process improvements or streamline the efficiency of this task? Is a new AR software package being installed that will change this procedure? Is the organization considering building an interface from AR to CRM? From CRM to AR? This reinforces the importance of understanding why a project was initiated (see the section on project initiation in Chapter 3).

If a project was initiated as a process improvement project, understanding the current system is very important when making recommendations for changes. If you will be proposing a change, you will probably be asked to present your reasons for the recommendation. Showing the current process next to the proposed process is a great way to articulate the improvements that you anticipate. In addition, when planning for the change itself, it is important to know where you are starting from to build a detailed change plan. In other words, if moving from A to B, you need to know where A is to make the move.

If a project was initiated with a solution already selected (e.g., a new AR package), recommendations will be limited to how to best utilize the new functionality. In this case, it may not be necessary to formally present the as is state because the organization has already decided that it is inefficient or not appropriate. In this situation, the BA needs to understand the as is state to the extent that important tasks are covered by the new system and to write conversion requirements, but may decide not to create any documentation about the old procedures or processes. The as is state is old because the organization has already decided on a new process.