There can certainly be some confusion with what project scope actually is. Like many terms used consistently within any business, project scope can become a cliche instead of an actual definition of what’s being done, so having people like Craig Brown clarify the term is always a good idea for both new and experienced project managers and IT execs. Traditionally, Brown says, project managers are looking at the scope of the work that will be done to provide a solution to the customer. The scope of that work is what defines the cost and time that must be used to complete that work. Citing the expertise of Julian (Chief Architect and contributor to the IIBA blog) to illustrate where the mindset of project scope comes from: Julian points out that the IIBA/BABOK’s approach to scope is framed around the delivery of a product/solution. This approach comes out of the realm of product management and is about defining what a product can do in terms of features and functionality. Many modern software project managers also talk about scope in the context of the product rather than the work to be done. In this context we talk about the “scope of the product” or the “scope of the solution,” not the scope of work. So you have project managers discussing scope of work and product managers discussing scope of the product. This can lead to some difficulties in understanding. Which definition is more important? Brown states that there are a few problems with defining scope by work: it’s a limited view, puts costs over quality, and risks not providing what your customer wants.