Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  CBAP - Certifie...  Have you wondered (about the BABOK 2.0) ...
Previous Previous
 
Next Next
New Post 8/20/2012 4:55 PM
User is offline Chris Lewis
5 posts
10th Level Poster


Re: Have you wondered (about the BABOK 2.0) ...  

@Ibtisam:

I’m glad to hear that we’re helping ;-)

2.5.4.3: Yes, this section is not entirely consistent. In this case, it is saying why you would record 'Author', rather than defining it. Are we using the same definition? You seem to be storing 'Business Analyst' in the Author field, where I would store the person's name, eg 'Kimbo'. That way, I could contact the person directly... as in, "Hey Kimbo, mate, what did you mean by that?" It would be more likely that the author is also a BA, so I could interrupt them more easily and effectively than the Source, who is busy doing their job and perhaps can't remember or explain it well.

2.5.4.2 Traceability. Yes, I agree, the wording would have been better with your text. Not only is 'type of views of requirements' more accurate, it prevents the confusion from readers who parse the text as 'number of views' (a web term) instead of 'number of views of requirements'.

2.2.5.1: No, they included the word "Definition" because the Techniques sections list the names of the Techniques listed in Chapter 9. They needed to use the full name.

2.2.5, 9.27: an example of a stakeholder who interacts with a solution, but is not in scope: We recently had a project involving the flow of information from system A to system C. The information flowed via system B, which was a system used by technicians visiting customers' houses. System B was in a lockdown phase, so we were not allowed to make changes to it, but we needed their cooperation for testing.

Interestingly, the eventual solution chosen involved a change to system B, so they came into solution scope.

2.2.4.3: You make a good point: it is the Project Manager's job, or the Change Analyst's job, to deal with the risks relating to low levels of influence.

I looked at the definition of the Task Output: Stakeholder List, Roles and Responsibilities (section 2.2.7). This includes "Description of stakeholder influence and interest". The output is used for Task 2.3 - Plan BA Activities, for which the output is the BA Plan.

Perhaps the BABOK authors decided that the BA will be the one who discovers this risk, rather than the Project Manager. In any case, as a BA, it is valuable information to know, even if it's not formally documented in the BA Plan or the risk register.

In summary, your main point is right - the BABOK should be unambiguous and logically correct. It's not 100% at this stage, but it does reward patience and further reading.

Work on BABOK Version 3 has started... I have volunteered to be a reviewer... so we'll see what that brings.

Cheers

Chris

 
New Post 8/23/2012 2:08 PM
User is offline ibtisam.jawad
15 posts
9th Level Poster


Re: Have you wondered (about the BABOK 2.0) ...  
Modified By ibtisam.jawad  on 8/23/2012 4:09:06 PM)

Please see below ...

 Chris Lewis wrote
 

@Ibtisam:

I’m glad to hear that we’re helping ;-)

2.5.4.3: Yes, this section is not entirely consistent. In this case, it is saying why you would record 'Author', rather than defining it. Are we using the same definition? You seem to be storing 'Business Analyst' in the Author field, where I would store the person's name, eg 'Kimbo'. That way, I could contact the person directly... as in, "Hey Kimbo, mate, what did you mean by that?" It would be more likely that the author is also a BA, so I could interrupt them more easily and effectively than the Source, who is busy doing their job and perhaps can't remember or explain it well.

I did not mean the "role". It should be the name of the Business Analyst that's stored there or whoever else actually documented the requirement, as you said e.g. Kimbo. Originator should go in source e.g. Jane smith. That's the person who "created" the requirement.

2.5.4.2 Traceability. Yes, I agree, the wording would have been better with your text. Not only is 'type of views of requirements' more accurate, it prevents the confusion from readers who parse the text as 'number of views' (a web term) instead of 'number of views of requirements'.

Number means just that, something that identifies a count. It can never be construed to mean "type" even from the context of that paragraph. I agree that BABOK should be better written than it is. Perhaps the authors of it are watching this thread.

2.2.5.1: No, they included the word "Definition" because the Techniques sections list the names of the Techniques listed in Chapter 9. They needed to use the full name.

Understood. Readers, especially nitpicking ones like me, would've fared better if the technique was labeled differently.

2.2.5, 9.27: an example of a stakeholder who interacts with a solution, but is not in scope: We recently had a project involving the flow of information from system A to system C. The information flowed via system B, which was a system used by technicians visiting customers' houses. System B was in a lockdown phase, so we were not allowed to make changes to it, but we needed their cooperation for testing.

Interestingly, the eventual solution chosen involved a change to system B, so they came into solution scope.

I still think that anything that's affected directly or indirectly by requirements is within scope for that project/iteration/sprint. From your example, despite system B being in a locked down state, you [probably] had to ensure that System A provided sufficient information in a certain way to System B, so that System B could relay it forward to System C, enabling some job function to be completed. Clearly then the requirements for your project for System A were shaped by expectations/limitations of System B. You had to consider these in scope, and involve some kind of integration testing with System B at the end, to call the new System A a success/failure. All those invesigations/tests into the limitations of System B took someone's time. You had to have considered these activities in scope to budget time and resources to them. Otherwise you were probably faced with scope creep at some point in the project. I'm just speculating based on my understanding of things, and things may actually have been different for you.

As for the statement written in front of 9.27 (under 2.2.5), I would rephrase it to: "Scope models should identify stakeholders that fall inside the scope of the solution, as well as those that fall outside of the scope of the solution." Clearly Stakeholders that are inside the scope are just as important, if not more so, than the ones that are outside.

2.2.4.3: You make a good point: it is the Project Manager's job, or the Change Analyst's job, to deal with the risks relating to low levels of influence.

I looked at the definition of the Task Output: Stakeholder List, Roles and Responsibilities (section 2.2.7). This includes "Description of stakeholder influence and interest". The output is used for Task 2.3 - Plan BA Activities, for which the output is the BA Plan.

Perhaps the BABOK authors decided that the BA will be the one who discovers this risk, rather than the Project Manager. In any case, as a BA, it is valuable information to know, even if it's not formally documented in the BA Plan or the risk register.

I agree that knowing "who calls the shots" can be useful for a business analyst when identifying requirements and working with the team to assign priorities in the real world. It does not however have any direct forbearance on Business Analysis Activities or Business Analysis Plan. How would I use my knowledge of stakeholder influece in my plan? Should I say for example, "John Smith has a lot of influence on the project team. Jane Smith, despite being an important stakeholder to the project, does not command much influence within her team. Now say that Jane created a requirement that clearly would be needed to accomplish a business goal, but John disagrees with it and wants to exclude it from the scope not knowing the impact it may have; since I know who has more influence should I not really bother much because I know that John is actually calling the shots. Neither should anyone else bother on the project team, because John might influence his team to cut the budget." What good does that do?

In summary, your main point is right - the BABOK should be unambiguous and logically correct. It's not 100% at this stage, but it does reward patience and further reading.

Work on BABOK Version 3 has started... I have volunteered to be a reviewer... so we'll see what that brings.

Cheers

Chris

I'm glad we're having productive discussion on the BABOK. Perhaps some of what we disucss will be useful for someone.

Regards,

Jawad

 
New Post 9/2/2012 11:11 PM
User is offline Chris Lewis
5 posts
10th Level Poster


Re: Have you wondered (about the BABOK 2.0) ...  

Hi Ibtisam,

I can understand your frustration... you make some good points.

One think I don't like about Techniques in the BABOK is that Section 9 only lists Techniques that are used by more than one Task. There is no section that lists all the Techniques - you have to check each Task, looking for sections like 2.2.5.2 and 2.2.5.3, if you want to study all the techniques that a BA should know.

Regarding 2.2.4.3: If you know that John has more influence than Jane, and that John disagrees with something that Jane wants, even though it meets a business goal, then perhaps your BA Plan could include the strategy to meet with Jane when John's not present!

This would give Jane a better chance to justify the need. You might also find out other requirements that Jane has not been able to justify.

If you are aware of high/misued influence, then you can plan for it. If you document it, your fellow BAs will be aware of it, and can avoid the potential trap of listening only to the most influential stakeholder.

Just a thought, anyway.

Cheers

Chris

 
New Post 10/26/2012 3:28 AM
User is offline smarg
1 posts
No Ranking


Re: Have you wondered (about the BABOK 2.0) ...  

 Hi Chris,

Any chance you could provide your Knowledge Area Input / Output diagrams to the forum?

 

Cheers,

Saul

 
New Post 10/26/2012 9:21 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Have you wondered (about the BABOK 2.0) ...  

Hi:

There are INTEGRATED input/output diagrams.  These are called Data Flow Diagrams.   Then there are NON INTEGRATED input/output diagrams.  These are simply called "input/output diagrams".     

Per lean six sigma (and a bunuch of other sources), a process is literally defined by its inputs and outputs, so identifying  inputs and outputs - especially on larger scale efforts - is critical if the BA wants to nail down the essentials.

Problem:  Especially on larger scale efforts, if the BA does not take an INTEGRATED approach, he/she will just get a very disjointed understanding of the system at hand.  

Tony

 

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  CBAP - Certifie...  Have you wondered (about the BABOK 2.0) ...

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC