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
