Scope - A case of Yin and Yang?

I recall a friendly debate I had with my boss a little while ago relating to defining project scope.

In her opinion, which she staunchly defended I might add, was that specifically detailing a list of items that were out of project scope was pointless. The rationale for this argument was that if the list of items which were classed as in scope for the project was clear and complete, this would thereby automatically imply that anything else was out of scope.

I also heard this argument supported in a "Project Management Training Podcasts" episode entitled "APMP Scope Management", whereby even the two presenters had this debate and shared different opinions!

I personally do not agree with this approach and I always give a list of bullet points in PIDs to clearly specify what is in, and what is out.

People are just not wired up exactly the same (who'd have suspected it, eh?). Some people are very forward focused in their mindset and will look at the "in scope" list primarily to crystallise the boundaries in their mind from the inside out, whereas other people will focus on the "out of scope" list to define where the boundaries are from the outside working in.

I'm a certified NLP practitioner and in NLP terms, the factors at play here are known as meta-programmes (Towards vs Away From), which basically means the personal preference for processing information, and which also overlaps quite nicely with some very interesting research by Dr Heidi Grant Halvorson on Promotion and Prevention focused people, which is well worth a read and can be found here.

For me, adding a list of Out of Scope items is essential as without it, there is a risk of assumptions being made about what the project is going to deliver (and assumptions will be made!).

A very simple (and high level) example would be:

"In Scope

• Hardware procurement and installation
• Server configuration
• Application build
• Testing
• Implementation
• Support model handover
• Staff training
• 1 month warranty period

Out of Scope

• Staff recruitment
• Disposal/reallocation of legacy system hardware"

For me, this adds a great deal to the overall picture that you are intending to define for the project, and when it can be stated in just a few words, then why wouldn't you? Obviously, there is no need to specify items that would be so blatantly out of scope, that they wouldn't even justify the keystrokes for you to record them or the executive effort to read them - so keep it relevant.

For me, the key thing to consider when listing the items that are out of scope is to apply common sense and ask yourself:

• What assumptions regarding this project scope could be made?
• What would be the impact if something was assumed incorrectly?
• How likely and reasonable an assumption is it for others to make that it would be in scope?
• What is a relevant boundary to specify for the specific project to remove ambiguity?

My boss still doesn't agree with me on this one, but that's not a problem. It's always nice to take in other perspectives!

What do you guys think? I'd love to hear some of your views about how scope is defined in your projects and organisations.