Business Analyst Blog

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

OK, I'm coming clean.  My all time favorite movie is Rocky, Rocky II, Rocky II, Rocky IV, Rocky V, and Rocky Balboa.  Every now and then I watch one of the movies and never get tired of the scenes of Rocky training or battling the next opponent in the ring.  But, there is more to the Rocky movies than just boxing.  There are lessons we can all learn from Rocky Balboa. I decided to dedicate the next set of blog posts to the greatest boxer to ever live!

Go ahead and launch the Rocky Theme Song while you read!

Mentorship

As part of our personal and career development we should all find mentors and be a mentor for someone else.  There are many benfits to being a mentor including working on your listening and leadership skills.  Being a mentee will allow you to learn valuable lessons from someone who has priceless experience and has been where you have at this point in your career. 

Throughout the Rocky movie the concept of mentorship kept popping out to me.  There is a scene where Little Marie is hanging out with some older boys on the street corner and Rocky pulls her away and walks her home.  During the walk home he is trying to give her advice about life and how the people she associates herself with will influence who she is as she grows up.  As Little Marie is walking into her house she turns and says to Rocky. "Screw you creepo!"  As Rocky walks away he mumbles, "Yeah, who am I to give advice."  Don't think you can't be a mentor. You have expereinces that can help others.  Little marie ends up thanking him later. 

Later in the movie after Rocky decides to fight Apollo Creed he does not accept help from anyone to help train and prepare for the fight.  Finally he comes around and gets Mickey to be his trainer and even gets Paulie involved.  In the end he is prepared for battle.  We all need mentors, we can all learn from others that have experienced things we have not.  Do not be ashamed to use a mentor.  You do not have to do this alone. 

As BA professionals you can find mentors and mentees within your family, company, or orginzations like the IIBA.  Also, check out this site for mentoring tips.  http://www.mentoringgroup.com/

Please share you mentor/mentee experiences with us.   

I have found that many BAs cringe when talking about software testing. They don't want to test and don't seem to want to learn the basic testing principles. I fell in love with testing when I learned about the best practices and all of the techniques. When you are testing, your goal is to find problems. What other job encourages you to look for and point out problems?? The more problems you find the more successful you are! And of course, the ultimate goal of all quality assurance is to improve the quality of our solutions!

Five reasons that BAs should love testing:

1. Thoroughly testing (and fixing) the solution before deploying ensures that users will be very happy with your work.

2. Having testing principles in mind when developing requirements helps to improve every single requirement. If you are constantly wondering "How would I test this?" you are more likely to develop complete requirements.

3. Executing tests and investigating defects teaches you more about how software applications are created. If you don't have a technical background this is a great way to learn more about what developers do and improve your communications with them.

4. Executing tests gives the BA a hands-on opportunity to imagine the best rollout strategy for your business stakeholders. When you have entered data into the software and generated reports, etc. you will easily be able to help the business area make the transition to the new system.

5. BAs learn to really appreciate SQA professionals and treat them better when they are available. Having been involved in testing, you will understand the work of SQA people and hopefully request them on future projects.

 So, the next time you are asked to help with testing - smile and enjoy!!

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.

It is so important for people in the business analysis role to build strong, solid relationships both in and out of the office.  Many people dislike the term "networking," but I feel it is one of the most important skills of a successful BA.  By helping others and asking for help, solid relationships are formed.  Here are two key reasons you should always be working on your network to improve both personally and professionally.

1. Knowledge and Experience: 

"No one lives long enough to learn everything they need to learn starting from scratch. To be successful, we absolutely, positively have to find people who have already paid the price to learn the things that we need to learn to achieve our goals."

-Brian Tracy, Author

You can't know and experience everything.  What you can do is be connected with people that have the knowledge and experience you need at any moment. 

2. Access and Openness:

Your assignment is priority #1 for you.  It may not be for the SME's and other stakeholders you need time from.  By having built relationships with those you work with the necessary doors will be open and time will be given.

Trust is a big part of a good relationship.  Your SME's will be more open and honest with you during a project if they trust you. 

Work on building your network…you wont be sorry.  Here is a great resource that has helped me over the years.   

When I was a young buck I could not beat this one kid on the block in a 100 yard dash.  I was convinced it was my worn out shoes causing me to lose time and time again.  I pleaded and begged my parents to buy me a new pair of sneakers for weeks.  Eventually they gave in.  I got the pair I needed to take down the champ.  As soon as we got home, I ran out into the street and lined up for the big race.  Guess what, I lost. That is when I figured out it was not the shoes.

So how does this relate to business analysis?  Like shoes I now put less emphasis on the title business analyst.  Is someone with the title of business analyst excellent in the tasks and techniques required of business analysis.  Not necessarily.  We should not focus on the title as much as the role.  Every successful project team does not need a business analyst, but they better be doing business analysis.

Agree or disagree?  Have something to add?  Please share.