Comments on: Getting Started Part I – Scope or Stakeholders? http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/ Connecting Business Requirements to Technology Mon, 30 Jan 2012 21:31:56 +0000 hourly 1 By: Angie http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/comment-page-1/#comment-900 Angie Wed, 23 May 2007 16:29:10 +0000 http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/#comment-900 Scott the short answer is "it depends", however the BA cannot gather requirements if they do not know the scope of investigation for the project. Establishing the area of study is typically the responsibility of the BA. BAs need to know which processes will be investigated, the boundaries of their investigation, what processes are out of scope and which stakeholders they will need to consider during requirements elicitation. Sometimes the PM and BA work together on this activity. The PM does have ultimate responsibility to manage project scope and project stakeholders. Scott the short answer is "it depends", however the BA cannot gather requirements if they do not know the scope of investigation for the project. Establishing the area of study is typically the responsibility of the BA. BAs need to know which processes will be investigated, the boundaries of their investigation, what processes are out of scope and which stakeholders they will need to consider during requirements elicitation. Sometimes the PM and BA work together on this activity. The PM does have ultimate responsibility to manage project scope and project stakeholders.

]]> By: Scott http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/comment-page-1/#comment-899 Scott Wed, 23 May 2007 13:22:41 +0000 http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/#comment-899 My question is how is managing the scope and stakeholders the responsibility of the BA? I have always thought this was the role of the project manager. In the company I work for, our BA's have their hands full gathering the requirements, analyzing the needs, and then designing a solution within the scope that has already been defined for the project. If they have to take on the additional project manager's tasks also, then the BA get's too busy managing the project to actually do the analysis and design work needed to satisfy the business needs. Is my thinking about this too far out in left field? My question is how is managing the scope and stakeholders the responsibility of the BA? I have always thought this was the role of the project manager. In the company I work for, our BA’s have their hands full gathering the requirements, analyzing the needs, and then designing a solution within the scope that has already been defined for the project. If they have to take on the additional project manager’s tasks also, then the BA get’s too busy managing the project to actually do the analysis and design work needed to satisfy the business needs. Is my thinking about this too far out in left field?

]]> By: Angie http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/comment-page-1/#comment-898 Angie Wed, 02 May 2007 17:31:03 +0000 http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/#comment-898 I agree with Mary that most often at the beginning of the project we do know a partial list of stakeholders. I have been on projects which started with a problem statement and a sponsor was not identified. It was after some investigation of the problem, that a sponsor and stakeholders were identified, as well as the business area boundaries for requirements. I agree with Mary that most often at the beginning of the project we do know a partial list of stakeholders. I have been on projects which started with a problem statement and a sponsor was not identified. It was after some investigation of the problem, that a sponsor and stakeholders were identified, as well as the business area boundaries for requirements.

]]> By: Mary http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/comment-page-1/#comment-897 Mary Tue, 01 May 2007 17:35:19 +0000 http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/#comment-897 While both scope and stakeholders may need to be managed constantly, I believe at least a partial list of stakeholders should come first. Typically a project has a sponsor/champion/owner who has some idea of who the stakeholders should be. As the scope is determined, additional stakeholders may be identified, but determing scope without stakeholder input seems risky. While both scope and stakeholders may need to be managed constantly, I believe at least a partial list of stakeholders should come first. Typically a project has a sponsor/champion/owner who has some idea of who the stakeholders should be. As the scope is determined, additional stakeholders may be identified, but determing scope without stakeholder input seems risky.

]]> By: Angie http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/comment-page-1/#comment-896 Angie Tue, 17 Apr 2007 13:05:52 +0000 http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/#comment-896 These are wonderful insights - keep them coming! These are wonderful insights – keep them coming!

]]> By: Craig Brown http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/comment-page-1/#comment-895 Craig Brown Wed, 11 Apr 2007 08:34:30 +0000 http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/#comment-895 Actually both scope and stakeholders need to be <a href="http://betterprojects.blogspot.com/2007/02/how-is-marketing-relevant-to-projects.html" rel="nofollow">managed constantly</a> throughout the project. For example, impacts to stakeholders can change even when nothing changes in the project scope so you constantly need to be scanning for stakeholder impacts and priorities. The same can be said for scope - just because a document has been signed off doesn't mean the scope is stable. It's a constant battle to mange the scope along the pathway of do-able and keeping the customer happy. Cheers Actually both scope and stakeholders need to be managed constantly throughout the project.

For example, impacts to stakeholders can change even when nothing changes in the project scope so you constantly need to be scanning for stakeholder impacts and priorities.

The same can be said for scope – just because a document has been signed off doesn’t mean the scope is stable. It’s a constant battle to mange the scope along the pathway of do-able and keeping the customer happy.

Cheers

]]> By: obv http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/comment-page-1/#comment-894 obv Tue, 10 Apr 2007 20:56:07 +0000 http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/#comment-894 I agree; getting the requirements from the stakeholders perspective is a good initial step. Since stakeholders drive the project, getting their buy in and perspective is key and may limit reworks which may affect the PM's deliverable. Developing an initial draft of the scope may be done in any order. It is an excellent way of grounding the BA into the project in the initial phase. I agree; getting the requirements from the stakeholders perspective is a good initial step. Since stakeholders drive the project, getting their buy in and perspective is key and may limit reworks which may affect the PM’s deliverable. Developing an initial draft of the scope may be done in any order. It is an excellent way of grounding the BA into the project in the initial phase.

]]> By: Niranjan B http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/comment-page-1/#comment-893 Niranjan B Tue, 10 Apr 2007 16:44:06 +0000 http://www.b2ttraining.com/2007/04/09/getting-started-part-1-scope-or-stakeholders/#comment-893 True, it really shouldn't matter as to "Which is done first": however, a preliminary level of understanding of the stakeholder before defining the requirements would always put me in the driver's seat, as it would not only enable me to fine tune the requirement inline with the stakeholders' expectation of the application (for example, simple, complex etc), but also visualize the requirements from stakeholders perspective - which would ensure fewer rework in future. True, it really shouldn&#39;t matter as to &#34;Which is done first&#34;: however, a preliminary level of understanding of the stakeholder before defining the requirements would always put me in the driver&#39;s seat, as it would not only enable me to fine tune the requirement inline with the stakeholders&#39; expectation of the application (for example, simple, complex etc), but also visualize the requirements from stakeholders perspective – which would ensure fewer rework in future.

]]>