Solution Scope vs. Project Scope

Solution Scope vs. Project Scope

Scope StatementMany project managers and business analysts seem to have a difficult time grasping the difference between project and product scope. These two paragraphs help to clarify the difference.

Project Scope: Project Scope includes all the work that needs to be done to create a product, or deliver a service or result. Project Scope is all about the project; it defines the work required to create and deploy the product. The project manager prepares the project scope statement.

Solution Scope:  The Product or Solution Scope is the characteristics, features, or function of the product or service that is to be built.  Solution scope is all about the solution to be implemented: how will it look like, how will it function, and other characteristics, etc. A business analyst prepares the product or solution scope.

The purpose of the solution scope is to conceptualize the recommended solution in enough detail to enable stakeholders to understand which new business capabilities an IT business solution will deliver.  Written correctly, the solution scope will create a shared vision. For enterprise projects, the scope statement is often written based in impacts on people, processes, and technologies. The solution scope is often validated in the capability gap analysis.

Creating a shared vision concerning the business solution, at this point in the project, will help the requirements elicitation process stay focused, significantly reduce scope creep, reduce timelines freeing up resources sooner, and increase stakeholder satisfaction. A well-defined solution scope significantly increases the probability of a project success.

However, according to a recent study, the lack of clarity in the scope of the business functions is the number one challenge for business analysts on projects.  The role of the business analyst is to define business solution boundaries to ensure that the solution scope definition aligns with the business needs. Not properly defining the solution scope can result in many problems.

There is a bowling ball effect when the scope has not been well defined.  The solution scope is used to define the requirement specifications. If the solution scope is not clearly defined, non existent, or not understood, then the translation of the customer’s needs will result in vague requirements which may not be properly understood. The subsequent design documents may, therefore, be poorly defined and documented, and the final solution will not meet the customer needs. The BA must work closely with the project manager to ensure that both a project and a solution scope have been carefully defined and are aligned with each other.

Now everyone should whole-heartedly agree that have a well-defined solution scope is strategic to success. Scope statements are needed whether the team is building a custom solution or implementing purchased software. However, there are very few articles or other resources that provided detailed guidance on building scope statements. Let’s look at how to define scope statements.  Too often, business processes and product scope are defined at a very high level. For example, I have seen that many scope statements read something like: “Implement the ‘SAP Purchasing module.’”  From this statement, how can someone tell what business activities and features are in or out of scope?

The strategic objective of a scope statement is to define focus!!! Without focus, all requirements elicitation best practices will be done in vain. Scope statements should have the following characteristics.

  1. Be clear and concise
  2. Contain a short description that explains the business purposes
  3. Be prioritized
  4. Support a business objective
  5. Focus on the solution, not the work to be done, which is defined in the project scope statement
Solution Scope – Process
Scope Description Priority
Purchase Order Processing Our current purchase order process has many problems.  The goal is to redesign the process to use the Peoplesoft purchasing module. High
Receiving Process We currently use manual procedures to check items received from vendors in the warehouse. The goal is to provide the warehouse with computers so that the warehouse workers can check the items received against what was ordered. High
Solution Scope – People
Scope Description


Purchasing Department The purchasing department will need to be trained on the new process and the Peoplesoft system that support it.


Warehouse The warehouse staff has never had computers before.  They will need to be trained in the new process, basic computer literacy, and on the PeopleSoft system.


Vendors We will have to work with our vendors to implement the new process. They will have to give us catalog information and work with us on testing.


Solution Scope – Technology
Scope Description


PeopleSoft Purchasing Module We own the PeopleSoft purchasing module but did not install it with the initial installation. The goal is to use this existing software and modify current processes to work with the new software. This involves all work to install and configure the base functionality of he Peoplesoft Software.


Purchase Order Processing Purchase order processing allows us to issue purchase orders to buy goods from preferred vendors.


Receiving The receiving process allows us to receive merchandise that we ordered and verified that nothing is damaged and that the order is complete.


Item Maintenance The item maintenance process permits creating and editing items that we order and receive.


Vendor Item Catalog Maintenance Item catalogs are groups of items that we can buy from a vendor. The item catalogs allow us to link our internal numbers to the vendor’s numbering schemes.


Vendor Maintenance This process allows us to create and edit vendor information such as vendor number, address information, phone numbers, etc.


Workflow Workflow consists of defining various business rules to govern the purchasing process.


Notice that the solution includes process, people, and technology components. Defining scope statements such as these up front will allow stakeholders to achieve a common vision and stay focused on the true scope during requirements elicitation.

Stakeholders should have a chance to review and comment on the solution scope. The project sponsor should approve them.  After approval by the project sponsor, the scope statements are used for eliciting requirements. Stakeholders are asked what are their needs pertaining a specific scope statement.  This will help keep requirements organized and help prevent or reduce frustrating out of scope requirements.

Many business analysts also like to define what is not in scope. This may be important given certain circumstances and should be done if it provides more focus for the stakeholders and project team. For the examples above, it might be helpful to list things in the list below as being excluded from the scope.

  • Procurement card processing
  • Sourcing
  • Vendor analysis
  • Purchasing analytics

A best practice for any implementation is having a defined scope change control process.  Unfortunately, having a scope change control process without also having a well-defined product scope statement will most likely result in failure.  How can any one identify scope creep when no one understands the scope?  It has been my experience that the majority of scope creep starts as discussions outside the standard project meetings where unclear expectations result in losing focus on the prize.  If the first time you hear of scope creep is in a change request then you are being more reactive than proactive.  I’m not saying that scope change is wrong or not necessary, but I am saying we should do everything in our power to minimize exploring requirements that do not align with the project objectives.

An effective ERP scope statement has to be more than just a document – it has to be a clear vision and expectation in the mind of your project team and business stakeholders.  Scope change control has to be more than a trigger for an implementation partner to create a contract attachment to their statement of work.  A clearly defined scope statement is a filter that enables business stakeholders, internal IT groups, and the implementation partner to align focus for mutual success.

1 Comment

  1. This is so far the only article that I’ve found in which the author clearly explains the importance of creating a shared vision and the benefits of a properly developed solution scope.

    Virtually all other articles that I’ve read about business analysis focus on requirements as the inception of a project rather than defining the concepts (for commercial software products and services) and business problems (for internal business improvement initiatives).

    Very refreshing, clear and informative article!



  1. Practical Tips for Project Managers – Professional Management Certifications - […] but will in a way bring a group of people who are focused in delivery and innovations in a…

Submit a Comment

Your email address will not be published.