Business Analyst Blog

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.

Business analysts are rarely allowed enough time to elicit, analyze, and confirm requirements. Why? One reason may be that we don't ask for it. An important BA skill is the ability to accurately estimate the amount of time required to perform analysis work and be able to explain and justify it to project managers and sponsors. Often they don't know why requirements take so long to "gather" because the word "gather" implies a BA with an Easter basket walking along the grass scooping up brightly colored eggs! It looks so easy!!

The best way to request and receive enough time is to build your case. You must be able to explain to the sponsor what you will be doing during that time and why your work is important. My suggestion is that you develop estimates by breaking tasks down into very small pieces. The smaller the task, the easier and more accurate the estimate. This detail also helps you justify the time. Let me give a small example - if one of my requirements deliverables is a Use Case diagram my task list might be:

Review project initiation documentation and draft UC Diagram   3 hours

Schedule stakeholder meeting (find room, call participants, prepare agenda)   1 hour

Conduct stakeholder meeting (present draft UC, get revisions)  2 hours

Revise UC diagram based on meeting  1 hour

Consult with IT architect to confirm feasibility   1 hour

Schedule review meetings with key stakeholders  2 hours

Conduct review meetings and ask for approval of UC Diagram  4 hours

By listing everything that you will have to do (including setting up meetings, etc) you will get an accurate picture of the time required. Remember these are work times - not lapse time. This is the amount of time that you would need if you were not working on ANYTHING else. Be sure to built in reviews and revisions as they will always be necessary. The less confident you are about the expected outcome of elicitation meetings, the more reviews/revisions cycles you should build it. Once you estimate, keep track of your actual work time so that you can learn and estimate even more accurately in the future. Take a look at our new course: Developing a Business Analysis Work Plan for more information. 

I presented a webinar for Catalyze (www.mycatalyze.org) on February 14th entitled Designing a Sure-Fire Stakeholder Strategy. The presentation touched on the importance of business analysis planning, specifically planning for stakeholder communications. We had 150 attendees and I was not able to answer all of the questions that were submitted. I will answer the remaining questions in upcoming blog posts.

How do I manage a stakeholder that changes his mind and these changes cause large amounts of re-work. Any rules of thumb such as an extra 20% longer?

Great question. When we are planning and thinking about how best to communicate with our stakeholders we need to consider each stakeholder's ability to provide requirements in a timely fashion. This includes considering stakeholders who may tell us one thing one day and something different the next. If you are fortunate enough to have personal experience with your stakeholders than you can plan for their individual idiosyncrasies (this is not a judgemental statement, we all have some percular ways of thinking and communicating!). If you don't personally know a stakeholder, try to find someone who does. Ask questions informally to get a feel for the person's style.

When building your task list and estimates, you should not explicitly say that you need more time with John because he changes his mind frequently, but you might build in more formal reviews and re-reviews with that particular stakeholder because you know this issue will come up. You also should alert the project manager that when dependencies are built into the project plan - beware that dependencies on John may be risky. The PM can also plan better with this knowledge.

We don't always get the dream stakeholders - the people who are always availabile when you need them, always patient when explaining their needs, and always sure about what they want. We have to learn to plan for and work with whoever our stakeholders are and remember than variety is the spice of life. If all stakeholers could clearly articulate their needs, there would be no need for a business analyst!

We, B2T, often get career advice questions coming in to our blog.  They mostly relate specifically on how to enter the BA profession and advance once in it.  I thought you all would be interested in an article I just read, "It Worked For Me: Career Advice from Top CIOs" by Martha Heller on CIO.com. 

CIOs from FedEX, Campbell's Soup and more talk about the best career advice they received.  The theme is about taking risks and stepping outside your comfort zone.  This is great advice whether you want to be a BA, CIO, Musician or circus clown. 

 I'd love to hear your feedback after you read the article.