It takes some planning on the BA’s part, but in the end, it’s a very effective way to run the analysis phase of a project. Here’s what you need to do. Each requirement for the project will contain one of three statuses:

• Draft – this means that the requirement is still being written and will not be a part of any meeting’s discussion.
• Ready for Review – any requirement with this status will be reviewed in one of the requirements workshops, or working sessions. This status is the one that the stakeholders will pay close attention to.
• Approved – the requirement has been reviewed in one of the working sessions, and approved by the stakeholders.

First, you need to plan the analysis phase of the project. As you do so, think about the logical groupings of processes and how they decompose. If you haven’t created a process decomposition diagram yet, now would be a great time to do so. It may be that not every stakeholder needs to be involved in every requirements workshop. This helps you keep only those people who are involved in the processes engaged. Once you understand all of the processes in scope, you have a better idea how to structure the requirements workshops.

Second, set your process as follows: each requirements workshop that you hold will have a basic agenda framework. The framework is set up as: review the requirements that are in a “Ready for Review” status, then discuss new requirements and processes. Since the workshops are planned around specific processes in the decomposition, it becomes very logical to review that way.

Once you finish the workshop, update the requirements as necessary, and change the status to “Approved”. Then, repeat the process in the next workshop. With each workshop, you are essentially reviewing requirements and signing them off. Each meeting is not as long as one final review, people are better able to stay engaged, and at the end of the elicitation, the document is (theoretically, at least) signed off.

Once you ask for approval at the end, all of the stakeholders have reviewed the document during the elicitation phase, and can quickly provide sign-off and approval at the end without a lengthy final requirement review. It also helps to remove swirl at the end since the requirements have been reviewed and discussed in the requirements workshops, and not several weeks later when thoughts and ideas have been forgotten.

This technique can be used with any metholodology, but having a requirements management (RM) tool makes it easier. How? First of all, the RM tool contains statuses for requirements. Having a status within the tool helps you manage them as you move forward. Secondly, the RM tool will help you with traceability. As you move through the document, you need to know how all of the requirements relate to one another. Changing a requirement in week 6 may affect one that was Approved in week 2. You need to know where those exist, and the RM tool really shines here.

Have you used a process like this before? How has it worked in your organization? Thoughts?

Executives develop strategies and overall goals for success.  These strategies and goals get realized through implementing projects.  Business Analysts have the critical role and responsibility to ensure the solution implemented via the project meets the company’s goals.  Are you feeling it? 

Besides having a good grasp of the techniques available to you as a BA there are two strategies of your own you should employ to make a positive impact.

1)      Lift your head out of the details and look where you are going.  Every now and then make sure your project is still aligned with the company goal(s) it is supporting.  If it is not, raise a flag to make the PM, your manager, and the business sponsor(s) aware.  You and your team should make adjustments to get the project re-aligned or push to have it canceled.  Stopping a project that no longer supports a company goal is a success, not a failure.

2)      Use the support network around you.  In the fast paced environment we work in there is not enough time for you to come up with solutions to the challenges you will encounter on your own. You do not have to do this alone.  At your company you are surrounded by an endless number of subject matter experts, other BAs, project managers, and a wealth of technical knowledge.  That is just the beginning. Look outside of your company and join and participate in local professional organizations like the IIBA.  There is no need to stop there.  Why stay local, when you can go global?  There are so many online communities where you can connect, interact, and learn from like minded people around the world.  Communities like BA Times, Modern Analyst, and a number of LinkedIn groups are great place to get answers to the business analysis questions you need answered.  Think about how valuable you are to a company by not only bringing your knowledge and expertise, but also bringing expertise from around the world.

Being a part of the future success of your company is wonderful.  Even though there is a lot of pessimism with the current economy it is an exciting time to be a business analyst.

To our success,

Kupe

User stories are brief descriptions or phrases written on an index card called a story card. They can be a great starting point for analysis because they are easy for users to describe and easy to document. They give an analyst or developer who is new to the business area examples of the type of work that is accomplished by the business. They also can be used to develop initial high level test cases.

The limitations of user stories are easily seen from the strengths above. They are not detailed and only describe a specific business transaction or situation. The number and choice of stories determines how well they, as a group, cover the scope of the business area. They do not formally call out data needs, business rules, or include consistent definitions.

For projects where user stories are dictated as the preferred requirements deliverable the experienced BA will be able to use them to drive down to detailed business and functional requirements which will complete the picture.

Tell us what you think!

Thanks, Barb

Day 1 - Pre Conference workshop – Sunday 10/26/08

I was thrilled to attend a Business Rules seminar by Ronald Ross who is often called the "father of business rules". I brought along his book Principles of the Business Rule Approach and he graciously signed it for me. Mr. Ross made a great case why we need to document and manage business rules independently of processes and program logic. He reminded us that rules have nothing to do with hardware or software technology and are only concerned with describing criteria for business decisions, business terminology and business facts. 

The best question a BA can ask the business stakeholder is why do we have this rule and how does it support the business strategy and objectives? The other main thing is to ensure that everyone is using the same definitions for business terms. He calls these rules facts. He made the distinction that business rules should be specified by business people, not IT. He showed us a fact model which looked surprisingly similar to an ERD. But not the same he declared. He also clarified the difference between rules (which represent decisions and are not procedural) and processes (they transform and are procedural). He was adamant that rules should not be included in processes. In documenting process workflows Mr. Ross never includes any diamond symbols. Diamonds represent decisions which need to be documented as business rule statements. He stressed rule independence from program logic is needed so that the business can manage their rules directly without getting IT involved and the business maintains control and establishes traceability. The great news is that Mr. Ross's seminar was aligned with the principles we teach to our business analysts.

The problem that we have with this phrase is that CMM and other sources who have been around for many years were using the phrases "Requirements Management" to describe the activities around eliciting, analyzing and documenting requirements. Since CMM was well established and well known it will be difficult for us to change the meaning of this phrase. In more recent years CMMI-Dev has narrowed the definition of Requirements Management but many people do not seem to be aware of the newly updated definition.

Many of the vendors selling requirements tools are doing a better job of distinguishing between performing requirements definition and requirements management.

You can Google "Requirements Management" today and find many different definitions.

I am interested in your thoughts about the use of this phrase and/or others you think create confusion in our industry. How does your organization use the term Requirements Management? How difficult do you think it will be to change people's perceptions and move to a consistent meaning?

The most common gap analysis is a comparison of required business data elements to the data elements supplied by the package vendor. This analysis can be as simple as "Does the needed data element exist in the package? Yes or No" or can be very complex including do the characteristics of the data match (e.g. CHAR vs. INTEGER), do the lengths of the data elements match, and do the validation edits match the business needs?

Another useful gap analysis is between terminology. Your business area may call its customer organization COMPANY while the CRM package that you are installing calls them ACCOUNTs. A table cross referencing these terms along with notes about how the package definition differs from your organization's definition is very useful throughout the project and after implementation.

Business processes can be matrixed against package features to make sure that all critical processes are supported. Notes in this matrix can explain how package features will be used or modified to support the business activity along with which role in the organization will utilize each feature.

Expand your use of gap analysis for COTS, department mergers, and even internal software development projects. Whenever you have an AS IS and TO BE system, there is a risk of gaps.

Hear me out!  I go to my gym to workout at least 3 times a week.  I go at different times each visit so I do not have the pleasure of getting to know the staff that well because of the changing shifts.  Each time I go to pick up my membership card when getting ready to leave I give the front desk staff my last name in the following manner, "Kupersmith with a 'K'."  Kupersmith is pronounced Coopersmith.  9 out of 10 times the person starts looking in the Cs for my card.  Or they look in the Ss and say Mr. Smith your card is not here.  I then repeat, "it's Kupersmith , all one word, with a K."  They quickly find my card and I leave.  I am supposed to leave refreshed and stress free, right?  Well this just gets me fired up.  It is obvious what happens.  They hear Kupersmith as Coopersmith or Smith and stop listening as I am saying "with a K." Now this is a simple issue that gets resolved in a matter of seconds, but it is still frustrating. 

This got me thinking how frustrating it is for our stakeholders when we as BAs to do not listen.  In my gym story the two main reasons I am not being heard is distractions and assumptions.  The staff is getting bombarded with phone calls and walk up requests. When they hear my name they are making an assumption of the spelling and stop listening.  

As BAs we need to multi-task with the best of them and having business and technical knowledge is needed.  But, when you are eliciting requirements focus on the task at hand and listen to the stakeholder.  Even with your knowledge of the application, process, business opportunity, etc., let the stakeholder finish their thought before you assume what they mean. 

This is not an easy task.  We need to constantly improve in this area.  Now stop listening to me and get back to work!!!