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!!!

Recently I participated in an interesting discussion about software development projects. There was an underlying assumption by some that using a consistent software development life cycle (SDLC) on all projects is a good thing and someone asked how to best enforce it. For me, enforcement is a morale killer. In working with many companies over the years developing software, some had methodologies and used them with great success, others used them but projects still failed. Some organizations, who did not have any standards, wasted a lot of time starting over for every project and still others without too many standards remained nimble and innovative with break-through and cost saving results. Training teams to make confident choices is more essential than dictating a methodology. I have argued with many quality assurance people when my judgment calls were in violation of a methodology step that did not add value to our efforts. Organizations should concentrate on teaching their employees approaches to handle different types of projects and challenges.

With training and project experience one can balance variables such as risk, cost, complexity, and importance of the project to determine which deliverables and efforts are beneficial. Does that mean you have to create a lot of paper documentation? It really depends on the project. Are lives at stake? If not, less formality and rigor is my preference. My mantra: Only work tasks that add value. Beware that most SDLCs are written for complex projects. If your effort is small in scope, has clear requirements, and minor business impact you do not need tons of documentation. Requirements may be confirmed informally. These are important considerations for a business analyst when planning.

I recommend organizations adapt a small number of easy- to-use development life cycles, provide people training and make the lifecycle options visible and available. I appreciate the overall structure, templates and reference that most development lifecycles provide to a project team, especially as a communication tool. Trained teams can benefit and develop efficiencies by having standards that work for different types of projects. Talented, experienced people can be creative and use good judgment to tailor the SDLC to what is important on their projects.

In other words, I know what I like to eat but it is also nice to select from the menu of my favorite restaurant. I can make my choices more easily, request menu adaptations as needed, and get to the fun part faster which is enjoying a good meal. Using software lifecycles for guidance, consistency and flexibility, need not constrain, delay, or negatively impact the project results or the team. They just let us get to our dinner faster and so we can enjoy the meal. I would love to hear your stories about methodology implementations at your organization.