2

There is one sentence at P120 5.3 Define scope (PMBOK 5th) confuse me a lot, it says:

The key benefit of this process is that it describes the project, ..... by defining which of the requirements collected will be included in and excluded from the project scope.

My question is that what kind of requirements will be excluded from project scope? Can you give me an example?

If one requirement was exclude from scope, should it keep staying in the requirement documentation? or should it be deleted from documentation?

2

During the initial phases of a project, requirements are not frozen and therefore they are in fact "candidates".

This allows working on requirements, and some of them can be cancelled to tailor the scope for the greater goal of the project. Also, some new requirements can be added to improve functionality, to acquire some new skills, etc.

However, not all requirements are relaxed/negotiable. There can be fixed requirements, such as the ones that the customer dictates, or the ones that come from government / industry regulations, etc.

Unless the project is a small and quick one, all requirements (obligatory or negotiable) must be kept under configuration control, and decisions must be documented. if some requirements are excluded from the scope, the justifications must be in the company documentations. This would be decided and defined in the scope of the Systems Engineering Plan of the project.

1

You might want to look at the MoSCoW model as an example - the W in MoSCoW stands for "Will Not" and represents requirements that the project will not fulfill.

I have written requirements of the form:

  • The project WILL NOT require remote logon
  • The project WILL NOT require specific software product to be installed on local systems
  • the product will not require the user to abandon existing procedures.

These are all ways of defining the scope by limiting the scope. I would want to maintain these requirements in the requirements trace-ability matrix to ensure that the finished product fulfills all of the requirements.

A sculptor once said that he just looks at a stone, sees the sculpture and carves away all the stone that isn't in the sculpture - requirements can be the same way - sometimes it is as useful to know what will not be in the finished product as it is to know what will be in the product.

0

Requirements will be either mandatory or optional. Optional requirements are prioritized based on approved criteria, one of which is usually cost. Those optional requirements that rank low are candidates for deferral.

Example: You are building a new home in a vacant lot, the size of which can include a pool and pool house, both of which rank lower on your family's list of priorities. Due to costs, you defer both.

Deferred requirements should never be removed from the documentation. They remain for historical purposes, including reasons why it was deferred. For those that are canceled, not deferred, they should remain, too, because of the reason for cancellation, and who approved it, needs to survive.

0

My question is that what kind of requirements will be excluded from project scope? Can you give me an example?

The decision to include or exclude a requirement is usually taken up by project manager by discussing requirements with project stakeholders. There can be different reasons as to why a requirement can be excluded, depending on the needs and priorities of project under execution.

Some examples :

  1. The requirement does not fit the core need of Product/service which you are developing.

  2. Completion of requirement may exceed the project delivery dates beyond the schedule.

  3. Cost of implementing in requirement may be too much high and may cause cost variance or impact cost baseline.

  4. Organisation may not have Human resource with appropriate skill to implement a requirement.

  5. Implementing a requirement could introduce Risk which may adversely affect project baselines such as scope, cost, time and quality.

If one requirement was exclude from scope, should it keep staying in the requirement documentation? or should it be deleted from documentation?

It is always better to have all gathered requirements to be kept in requirement document. In future, some of the excluded requirement can be taken up based on feedback/discussion with project stakeholders.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.