How to define out of scope for dependent function?

Question

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?

Answer 1

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.

Answer 2

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.