Business Analyst Blog

As the business analysis profession evolves we will get more consistency around our terminology. One of the phrases that is still used inconsistently is requirements management. Most experienced BAs use the phrase "requirements management" to mean the activity of "managing" the requirements. This includes tasks like deciding where requirements will be stored, how they will be documented, how they will be presented, how they will be maintained, who will update them, etc. This use of the phrase makes sense to me and I would like to endorse it. I also encourage organizations to maintain requirements after the project is complete and "manage" them over the life of the system/solution. Re-using requirements on future enhancement projects provides a huge productivity gain for business analysis work. 

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?

I recently read an article on CIO.com and thought you may be interested in seeing the Four Secrets to Becoming an IT Star.  According to this article, being an excellent BA will help you on the path to stardom. 

The fours secrets are

1. Be good to your end user
2. Go beyond the walls of IT and learn the business
3. Understand the organization's structure and goals
4. Build trust with your boss

Don't you agree those are all qualities excellent BAs possess?   This quote from the article sums it up for me. '"People outside of IT won't necessarily understand tech speak, so you need to present information in a manner so they understand technology and what it provides to the company," says John Murphy, CIO of Hard Rock Hotel & Casino in Biloxi, Miss. Murphy's ability to do so has helped him in the executive suite with other C-level colleagues. "I've been able to translate technical information to them in the manner they can understand and assimilate and in a way that shows the benefits to the big picture," he says. '

I have been saying for awhile that the next generation of CIOs will be coming from the BA ranks.  So keep it up and be a star in your organization.  Soar all the way up to the C-level!!!

You choose. Have you ever worked with anyone who complains about every task that comes their way? It makes the work day seem so much longer. Some people always seem to have a problem or reason why things go awry or they believe that their issue is always someone else’s fault. They can’t see that it is not the project, the people, or the business complexity that is the problem – it is their own attitude. 

In a normal working day we talk and interact often with our stakeholders, our teammates, our colleagues and our management. Our behavior allows those who work with us to view us in a particular way. On a daily basis you get to choose whether you will be perceived as someone who gets things done or as someone who gives reasons why things are not accomplished as committed.

I work with people every day that I consider to be “heroes”. I don’t mean like police or firemen that rescue people out of burning buildings but I do mean the type of people that make our jobs fun and exciting. My work heroes are positive individuals. They take what comes, especially challenges, and they create something so much better than we could imagine.  A work hero is someone who can muster enthusiasm and encouragement even when their colleagues are being negative, bemoaning the fact that they are working a difficult assignment. You know those projects from “hell” that everyone loves to brag about. There will probably always be victims in the world ready to point fingers and blame others for failures that occur. My heroes do not let themselves off the hook when there is a tough project and they work their magic by bringing people together to solve a problem in a very creative, unexpected way. Their secret ingredients are persistence, enthusiasm, generosity and hard work.  I am very fortunate that I do not work with any victims. My colleagues inspire me with their encouraging, optimistic attitudes.  

Unfortunate things do happen, but one way to tackle issues is to take pause and regroup to resolve problems or to replan work that is not going the way it should. Think, “What can I do to create a winning situation?” Often problems begin with poor communication. Keeping heated emotions out of work discussions is prudent and working cohesively through difficult times, rather than pointing fingers at our team mates work unexpected miracles.

When you look around I am sure you can see heroes and victims in your work environment.  Learn from the heroes and try to influence any victims you know to look introspectively if problems keep happening. It is not always easy to be positive but it is always a good idea to check our attitudes so that we are getting the best out of ourselves and others who we influence on a daily basis. I would love to hear comments about how heroes and victims affect your work places.  

I recently read an article in Time magazine, Mandela: His 8 Lessons of Leadership, that I recommend you read. As BA's we are leaders and need to continue to learn how to become better leaders.  After reading the article I would love to hear your thoughts on how the lessons discussed can apply to our position. 

I look forward to hearing from you!!!

Managing Business Analysts can be challenging and frustrating. There are several logical reasons for this difficulty. First, business analysis work is complex and the role is not well understood. Review a few BA communities and blogs and you will read varying opinions on what the job is and who best fills it. Most people who are managing BAs do not have experience in this role since the profession is so new. Managers often have analytical experience but in a very different business environment than we find ourselves today.

Second, most organizations don't yet have standards and consistent processes around the business analysis work. It is difficult to evaluate a BA's performance when there is not a clear performance standard around which to measure.

Another difficulty is that most BAs are very detailed-oriented people who are thorough and lean towards perfectionism. It is difficult for them to finish a task because the requirements are never perfect. Many BAs get stuck in analysis paralysis on a regular basis, leading their managers to believe that they can't get anything done.

Other reasons for the management challenge is that analysis work is by its very nature, difficult to plan and measure. BAs don't know how long it will take to "think about" a complex problem and come up with a solution.

Managing BAs will never be easy or straightforward, but there are some quick techniques that can be used to improve the situation. As with most challenges, recognizing the problem is the first step. Spend time with your BAs asking them to explain their work and their challenges in some detail so that you begin to understand the complexity with which they are dealing. Assure them that you have confidence in their ability to analyze and that you want to support their efforts as much as possible. Continue to remind them that a requirements document or business model will never be perfect or absolutely complete. Tell them that you (and their stakeholders) are not looking for perfection but are looking for the best work that can be done within the project timeframe.

Encourage BAs to reuse requirements templates from other projects and share techniques with other BAs. Encourage BA communities of practice so that BAs can learn from their peers. Allow BAs time to read blogs and articles about requirements management. One caution - don't fall into the management trap of thinking that a tool will solve your management problems. A requirements management tool will never replace a BA and will initially add to your management challenges because of the training curve and custodial resources required.

When a BA is stuck, ask her to tell you the risk of letting go. "What is the worse thing that will happen if we don't thoroughly document every process in the Marketing Department before we go forward with this project?" Help them to understand that there are some risks that you and the organization are willing to take.

Much of a BA's time is spent balancing a complete understanding of a problem/solution with the time/resource constraints of the organization. Helping your BAs to maintain a reasonable balance will make them more effective, develop them into senior BAs, and keep your projects moving forward.

I am reading an interesting book on certifications: Performance-Based Cerfication by Judith Hale. The first chapter has a great discussion about Why Organizations Certify and it is one that I think managers of BAs should consider.

Many professions and roles within the IT industry have developed certification programs and getting "certified" has become a hiring criteria for many positions. Business Analysis certification has been needed by many organizations and managers which have not had a method of evaluating BAs and the quality of their knowledge and skills. Now that the industry is developing standards and certification programs are available, should you encourage your BAs to work towards certification? Certification takes time and money. Managers should be sure of their reasons for or against certifcation.

One reason to support and encourage certification is to recruit and retain high quality staff. Professionals want to work for organizations that support professional development. If your BAs are working towards certification, hiring new BAs will be easier because candidates will see your committment to the profession. BAs are more likely to stay with their current employer when they feel their work is being recognized.

Another important value of certification is the establishment of consistent best practices and use of industry standards. Having your BAs all certify means that they have a common understanding of the knowledge and skills of the profession and that they use a common language when planning their work. This consistency of process supports initiatives like CMMI.

A third advantage of certication is to raise the core competencies of individuals in your organization. Even if only a few of your BAs have enough experience to certify today, setting certification as a long term goal for all BAs encourages them to build their skill set and work towards higher performance standards.

We are seeing many BAs work towards certification on an individual basis because they see potential value for their personal career development. BA managers should also consider the value of supporting BA certification.

If you have not read Part I and II of this blog series feel free to take a look.  At the end of Rocky II Rocky wins the title of heavyweight champion.  He is now very wealthy and defends his title 10 times.  In the beginning of Rocky III a real contender wants a piece of Rocky Balboa.  His name…Clubber Lang.

Stay Hungry

Rocky has been living the good life for some years now beating up on has-beens and raking in the cash.  When Clubber Lang comes along Rocky is not ready.  While Clubber was training to win, Rocky had his training sessions at a hotel taking pictures with fans, selling merchandise.  Doing everything, but training.  Rocky was not hungry.  He was the champ, what can stop him.  Well, Clubber Lang stopped him.  Rocky was not prepared and lost badly.

As BAs we always need to be prepared.  Every initiative we work on is different.  Just because we may have broad experience and a history of success we need to stay hungry.  Think of your next project as Clubber Lang.  Always remember to be prepared and have the eye of the tiger!

Don't be afraid of Change

After Rocky's loss to Clubber Lang, the great manager, Mickey Goldmill, died of a heart attack.  In a bizarre turn of events Rocky went to train with his old rival Apollo Creed to take another stab at Clubber. In the first bought Apollo noticed how slow Rocky was and that he needed some quickness to avoid the thundering blows from Clubber.  Apollo had Rocky focus on techniques that helped him move his feet.  Initially Rocky was clumsy and struggling through these techniques.  He was obviously frustrated.  To try and motivate Rocky, Apollo tells him "it takes a real man to change."  That was one piece that helped Rocky excel to another level and eventually defeat Clubber Lang.

My new saying now is "It takes a real BA to change."  I have said before we have to continuously learn and adapt to tackle the next project or situation.  Yes it will be frustrating at times, but the rewards are huge.  Don't be afraid to makes mistakes.  Those are the best learning opportunities.  And don't just talk with people that approach things like you do.  Find people at your local IIBA chapter or in your company that have a different style or take an alternative approach to situations. 

In the next installment we travel to Russia with Rocky.  Make sure you have your passport!

Gap analysis is a well established technique for business analysts working on COTS (Commercial off-the-shelf) package implementations. It is amazing that this simple technique can be helpful with so many analysis challenges. Most gap analysis is done in a matrix or table where the analyst can keep track of the business needs in one column and note the package support for each business need in another column. Consider a few of the common uses:

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.

A question most BAs get asked when assigned to a project is "how long will it take to complete requirements?"  Without going into ways to improve your estimating skills, I want to address a key point that is often missed when answering this question.  Our answer is usually related to our time and duration needed.  This is a core factor, but we also need to consider how much time is needed from our stakeholders. 

It is important for us to set expectations with all stakeholders that will be involved in the steps of eliciting, analyzing, documenting, reviewing and approving requirements.  The list of stakeholders to consider include SMEs, sponsors, PM, QA Analysts, and development staff.  In order for you to effectively meet your deadlines you need to receive the necessary time dedicated from these stakeholders.  Your project is most likely not their only project.  Planning for their time will help ensure they will be available when needed.

Simply put: lack of planning on your part  does not constitute an emergency for your stakeholders.      

If you have not read Part I of this blog series you can read it here.  In case you are not as familiar with the Rocky movies as I am, here is a little recap of what happens at the end of Rocky.  Rocky goes 15 rounds with Apollo Creed.  Rocky's right eye is badly damaged and the peripheral vision in that eye is all but gone.  At the end of the fight both Rocky and Apollo say there will not be a rematch.

Now on to Rocky II where we learn some important lessons about checking our egos at the door and never saying never. 

Ego

Since Apollo was supposed to finish off Rocky in 3 rounds in their first fight, Apollo was getting abused in the media and receiving a ton of hate mail.  Basically calling him a joke, washed up, etc.  Apollo then started calling for a rematch with Rocky.  Even though his trainers, managers, and family all thought it was a bad idea he kept pressing for a rematch.  He wanted this rematch because of his ego not because it was the right thing to do. 

As BAs we need to leave our egos at the "door" when working on projects.  The project is not about us.  Our goal is to do what is right for the project.  If your mindset is focused on the project needs, the project will be a success and you will get recognition.  Remember, it is not what the project can do for you, but what you can do for the project!

"There ain't no Can'ts"

A great line from the great manager Mickey Goldmill.  Apollo pushed and pushed until Rocky and Mick finally agreed to the rematch.  The problem was that Rocky's eye was so bad that he could not fight as Southpaw.  Since his peripheral vision was so poor he would never see punches coming from Apollo until they were right on his face.  So Mick was pushing Rocky to become a right-handed fighter.  After a number of times with Rocky saying "I can't do it Mick", Mick yells back "there ain't no can'ts." 

Every situation we encounter as BA's is slightly different.  The project characteristics are different, the people we work with are different.  We can not use the same techniques on every project we are on.  Always try to learn new techniques and skills and never say "I can't do it Mick." 

The next blog entry will be focusing on Rocky III where Rocky takes on Clubber Lang!