Corporate Education Group

How Should a Business Analyst Define Project Scope?

CEG offers Corporate Training and Consulting, as well as traditional and virtual instructor-led courses in management and leadership, project management, business analysis, business process management, agile/scrum, and lean six sigma.

Issue link: https://info.corpedgroup.com/i/1209582

Contents of this Issue

Navigation

Page 0 of 2

300 Brickstone Square • Suite 201 • Andover, MA 01810 USA • 1.800.288.7246 • +1.978.649.8200 • info@corpedgroup.com "You start coding, and I'll find out what the users want." It's an old joke, but today's business analysts are often confronted with a more modern version: "You start writing requirements, and we'll figure out the project scope later." Then we wonder why we have scope creep. All too often, a project's business requirements analysis begins when the project scope has, apparently, already been defined. But as business system analysis proceeds, stakeholders discover that they have very different pictures of the project scope, of what's in and what's out, and of what the new system is supposed to do. Project Scope Tools for the Business Analyst The responsibility for defining the project scope is often assumed by the project manager. He is likely to employ a tool — like a work breakdown structure (WBS) — to define the deliverables, such as requirements specifications, design plans, source code modules, and training delivery. The problem with a WBS is that it doesn't provide a clear enough picture of the functional requirements, and, as we all know, "the devil is in the details." Project managers must focus on the broad picture and How Should a Business Analyst Define Project Scope? B U S I N E S S A N A LY S I S

Articles in this issue

Links on this page

view archives of Corporate Education Group - How Should a Business Analyst Define Project Scope?