I am doing a project which have defined required functions for delivery assuming Function A.

During the requirement collection, it is found that the function depends on Function B which should be well developed. And Function B is critical to the whole function delivery.

Should I define the Function B is out of my scope?

  • Is Function B required for everything you originally scoped? Commented Aug 22, 2018 at 10:37

2 Answers 2


Scope, Assumptions, and Responsibilities Aren’t Synonyms

It sounds like you’re describing an assumption. Your project is assuming that Function B, which is an important dependency, is available and operates as expected. This assumption should be made explicit in your project planning documents and communications.

Meanwhile, your use of the word “scope” sounds like it’s more a statement about responsibility. If Function B isn’t available, or isn’t operating as expected, to what extent is addressing this out of scope for your project? Just because you may not be responsible for the successful delivery of Function B, sourcing and integrating true dependencies likely should be in scope.

For something to be truly “out of scope,” it should either be:

  • irrelevant to the success of your project, or
  • so fundamental to the project that any false assumptions about it should trigger an immediate re-evaluation of the project.

It may be worth thinking about what your objective is in describing this dependency as out-of-scope, and making sure that you are effectively communicating that objective to the project stakeholders.


The determination of in or out of scope depends on how explicit your supporting documents are, including your requirements baseline, spec sheets, architecture designs, engineering designs, etc., as well as how your contract is written. It is impossible for participants on this exchange to make this determination for you unless you want to upload all of these documents for us to read.

So this becomes about process...the change process specifically. Your team needs to come together and discuss this function B and review your supporting documents and then arrive at a position. Then sit down with your customer / product owner and discuss your case and uncover their position. If everyone agrees it is out of scope, and everyone agrees it is required, then trigger your change process and get it approved, paid for, scheduled, etc. Then carry on.

If they disagree and believes it is in scope, then you have a contract dispute. This triggers your escalation / issue process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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