Why Business Analysts Should Document "What We Won’t Do"

As Business Analysts (BAs), we often pour our energy into discovering, documenting, and refining what a system should do. But here's a critical element that often goes unnoticed and undocumented: what the system won't do.

This simple practice can be the difference between a smooth project and a frustrating one derailed by misunderstandings, scope creep, and rework.

The Importance of Documenting "Out of Scope"

1. Prevents Scope Creep

Scope creep happens when new features or changes are added to a project without proper evaluation, approval, or impact analysis. Documenting what is not included sets clear boundaries. It becomes your first line of defence when stakeholders try to slide in new requests mid-project.

Example:
In a customer portal redesign project, the team agreed to improve the login experience and dashboard UI. Midway, a stakeholder asked, "Why aren’t we also adding a chatbot for customer support?"

Having an "Out of Scope" section that states, "Live chat support integration is not included in this phase" makes it easier to say no without sounding dismissive.

2. Sets Clear Expectations

Ambiguity breeds assumption. If something isn’t explicitly ruled out, stakeholders might assume it's in.

Example:
In a project for automating leave approvals, HR assumed the tool would also handle payroll deductions for unpaid leaves. But that was never discussed.

The absence of an explicit note like "Payroll calculations are not covered in this release" led to disappointment, finger-pointing, and delayed delivery.

3. Protects the Team and Timeline

Clear boundaries protect the development team from taking on last-minute requirements that can derail timelines.

Tip: Don’t just say "X feature is out of scope". Go one step further: explain why it’s out of scope — budget, timeline, complexity, or dependency.

Example:

"Multi-language support is excluded in this phase due to tight delivery timelines. It may be considered in Phase 2 post-MVP rollout."

This keeps everyone aligned and builds credibility.

How to Communicate "What We Won't Do"

• Use a dedicated section in your BRD (Business Requirements Document), SRS, or Confluence page called Out of Scope.

• List bullet points for each exclusion.

• Reference discussions or decisions if needed.

• Reiterate in meetings, especially during kickoff or scope walkthroughs.

Pro Tips for Business Analysts:

1. Be proactive – Don’t wait for assumptions to surface. Ask directly: "Are there any expectations you have that we haven’t covered yet?"

2. Review similar past projects – This helps identify areas where assumptions commonly arise.

3. Collaborate with PMs – Ensure that your scope and out-of-scope sections align with the project charter and change control process.

4. Document assumptions separately but clearly – Many out-of-scope items come from invalid assumptions.

Conclusion

Documenting what you won’t do is just as important as what you will do. It protects the team, streamlines delivery, and keeps stakeholders satisfied, not surprised.

Out-of-scope documentation may feel like a small task, but it delivers big results in the long run.