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 5: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 3: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/3/2012 12:11 AM
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 4: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 10: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

Context:  Intro Change Request Definition Reasons for CRs Adaptive, predictive and mixed projects Flow of processing change requests Change Management Workflow Tools and Techniques 1. Intro  The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An or...
For many people, a career in business systems analysis can be an ideal opportunity to use their skills in technology and business. Business systems analysts bring together the best of both worlds – technical know-how and business acumen – to help organizations become more efficient and effective. Here are some of the key benefits of pur...
There is no doubt in my mind that curiosity nurtures the mind when it comes to T shaped skills.  T shaped professional are specialist in something(the vertical line) and also have a wide range of skills and knowledge in a broad range of subjects(the horizontal line) and are are highly sought after in the workplace.  I’ve recently...

 






 

Copyright 2006-2023 by Modern Analyst Media LLC