Collect requirements before Define Scope?

Discussion in 'PMP' started by _15734, May 17, 2018.

  1. _15734

    _15734 Member

    Nov 15, 2017
    Likes Received:
    Hi @tim jerome,

    In my projects, we have always defined scope, before we start collecting requirements. When I was reading through the 'Scope Management' KA, I saw that the Collect requirements precedes Define Scope.
    I was surprised initially.. but then I read this...
    "Since all requirements identified in Collect Requirements may not be included in the project, The Define Scope selects the final requirements" (PMBOK ed 6 - Pg 151)

    Which makes my point even more stronger! Why collect requirements for something that not be included in my final scope??
  2. tim jerome

    tim jerome Well-Known Member

    May 15, 2015
    Likes Received:
    The scope is derived from the requirements.

    Requirements are stated, "I need this, and I need that. It has to be this way, and this cannot be that way." I will take all the requirements and integrate them into a Scope Statement.

    The Scope Statement is a comprehensive description of the deliverable and work required to complete it, and is used as a reference as well as a communication device - establishing and confirming expectations.

    Scope is the actual, final item that you may have at the end of the project.

    There is a description of the scope before the Plan, and it's in the charter. You collect just enough of a description of what you will have, in order to gain project approval. The Charter will also have a high level overview of requirements as well.

    In order to understand how these processes fit together, you sometimes need to step out of your personal experience and consider all Project Management. In a major, critical project, you gain approval to move forward, then you collect all the wants and needs from the stakeholders. Then you integrate that into a single statement.

    It's slow and very plodding, but when you have a critical project, it's the best way to approach the work.

    Actually, your statement from the PMBOK reflects what is described here. First you collect all the requirements, then you select the necessary ones and use them for a definitive description of the deliverable in its end state.

    Why would I collect requirements that I may not use? Two good reasons:
    • The requirements and scope are both what the deliverable will be, and what the deliverable will not be. You will collect ideas, discussions, even requirements, and consensus will say, "no - we don't want this now", or "that's not really in line with the objective". This shapes the project as much as saying yes.
    • You will collect all the requirements, and then you won't know you don't want them all until you sort them out - analyze them. Just like change, you need to discuss, review, and vote before you confirm this is indeed what the project will be about.
    _29044 and _15734 like this.

Share This Page