Managing expectations and scope creep

As a business analyst you're going in and talking to stakeholders. These are the people who are actually either requesting the change or responding to the change. A lot of the time when they share something with you they believe they're going to get it. Just because they've shared it with you and through the elicitation and you've gathered it as a requirement, doesn't necessarily mean it's actually going to make it onto the final project. The reason is you've got to make sure that it aligns back to achieving one of the scope items. If it doesn't achieve one of the scope items it may be a great requirement but that's not what this project is expecting to deliver. While it's great to capture those requirements and save them and emphasize the fact that it's an out-of-scope item, the thing that we're there to focus on are the in-scope items. But more importantly as a business analyst you should never commit to anyone to saying that what they've been asking for will be delivered, because we've got to take each and every one of these requirements and wash them together for the overall context, and make sure we deliver against all the stakeholder scope items as well as the strategic objectives of the organization and project. That's where the alignment needs to happen. As I said the biggest concern that I would have is never, ever commit to a stakeholder that what they're requesting is what you're going to be delivering in the project, because there's so many other verification processes that need to happen later.