I agree with Sergio. Call it what it is, which is "out of scope". This is a point that I take very seriously during Project Charter and early in project planning. The Scope Statement should include a specific list of items that are "Out of Scope". These could arise from discussions with the stakeholders, steering committee, PMO, BA, and even the project team when creating and reviewing the Project Charter, and then during Requirements definition. Changes to the Scope Statement after acceptance need to go through the authorized change process, especially if being added to scope. Saving Changes...
Paul RadulescuBusiness Technology Mgmt| DeHavilland Aircraft of CanadaToronto, Ontario, Canada
I like to put on paper what's in scope, with the best of my ability to cover the details. For what's missing I like to term these as "will be eventually covered in the next phases" if I'm asked. You don't upset anyone for not having the resources to do everything at once. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I followed what John stated above from years and it works for me. Saving Changes...
Personally I like to call things by their name, in this case "Out of Scope"
All your stakeholders should understand, what is the scope, and why your aren't available to perform something outside of it.
As Paul said and Sergio agreed, in my IT world usually I've said, "this is out of scope, then can't do now. We keep in mind to share your request in the next phase", and usually the team or users understand it. Saving Changes...
If this is related to project management, I would go with "out of control within the boundary of project at the time of identifying and completing the scope". Saving Changes...
Community Champion
