What should you do first? Would you define your requirements scope before you start to identify and analyze your stakeholders or vice versa? Would you receive the same answer if you asked 10 Business Analysts? I would bet not. Many might answer that they identify scope first before they can identify requirements stakeholders. Others would start with the people whom they know are impacted by the project.
Does it matter which is done first? Probably not and I will tell you why. Typically you want to start with what you know most about the project. As a Business Analyst I continually ask myself two questions: what do I already know and what is most important to know next? Most project activities do not happen sequentially, especially during the planning process. It really doesn't matter which activity you do first as long as you focus on defining what you need to know most at the appropriate time on the project. In the beginning of the project you will want to understand the breadth of the project based on some key elements such as the scope and the stakeholders-and it really does not matter where you begin.
8 Comments
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.
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.
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
These are wonderful insights – keep them coming!
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.
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.
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?
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.