Search This Blog

Wednesday, February 1, 2012

The Approach

I have the privilege of mentoring and coaching many business analysts and I learn so much from each relationship I am a part of.  I had a very interesting mentoring session this week where my mentee and I talked about the steps she would take if all she received was the project scope, a list of 5 SMEs and was told to gather requirements to make changes to a web application.

I must first say she is relatively new to the business analysis discipline and currently reading through the BABOK.  As we ate lunch I thought it would be interesting to see what she would do in that situation, though she hasnt experience it yet. 

She advised she would do the following:

1.    She would do some sort of document analysis to determine what documentation is already present that she can learn from.
2.    She would then have a brainstorming session with the SMEs provided to understand their requirements and capture their requirements.

For someone relatively new to the discipline this was a good start. I told her that she was going in the right direction and we started to take more about some things she could ask and some more things she could do.  I had to emphasize that the approach she chose to take is key to project success and as she continues to do business analysis work she will get more and more skilled based off of past experiences on how she should approach certain projects. Let me state I'm not saying that the approach cannot or will not change, but there needs to be some serious thought on what should be done prior to jumping into business analysis activities. Through more conversation with this scenario we came up with the following as some additional things to consider, again this is not the end all list but it is amazing just through some conversation her two bullet points 7.

1.    Before diving into anything we decided we needed to find out more information such as:
a.    What is the timeframe for this project?
b.    Who are the stakeholders and what are their roles? (stakeholder analysis)
                                          i.    Who has worked with these stakeholders in the past? (What are their likes or dislikes? How do they like to be approached?)
c.    Clearly understand the scope
                                          i.    How does this project relate to the overall company strategy, goals, objectives, etc? (enterprise analysis)
                                        ii.    What is the desired goal of the project?
d.    Research what documentation already exists and learn as much as possible prior to any meetings.  Determine if information in previous documents can be leveraged in the project. (document analysis)
2.    Determine the methodology and documents to be completed and how those items are going to be monitored and tracked for success (business analysis planning and monitoring)
3.    Start Elicitation activities (determine meeting time, location, agenda, individuals to be included, obtain materials for the meeting such as flip charts, post it notes, etc...)

We stated to talk some of things that could occur in the meeting such as individuals that will not talk or the individuals that take the group off in tangents briefly. 

Based on this conversation she determined that there was a lot more to think about and consider before starting the actual work. This is an area that is a struggle for BA's new to the discipline and even those who have been doing business analysis for a while.  Getting started can be the challenge.

It's not about being quick to jump into the work but rather taking time to:

1.    Understand the problem to be solved, the timeline to solve it, the stakeholders and their roles, the overall goals and objectives of the enterprise. 
2.    Determine your approach to gathering the requirements such as methodology, documentation templates that add value, conduct documentation analysis to determine what already exists that you can leverage.
3.    Begin requirement activities (elicitation, prioritization, verification and validation, documentation creation, final approval)

There is clearly more to this than just what I mentioned above but at a high level this will get your going.

Paula Bell

No comments:

Post a Comment