Let us first understand about project scope:
Client: “I have a block of land. I want to build a standard one-story house according to this plan. Can you please give some pricing?”
Builder: “Why not sir! Looking at your house plan. It will cost you $250,000 for standard fittings. Note that it does not include tiles, curtains and lawn reticulation fittings (Not in scope). However, it does include wall painting and rendering (In scope)”
Client: “Ok! How much if I want you to include items that are not is scope?”
Builder: “Add $50,000 more to it. So it will be $300,000 in total”
So, Project scope includes deliverables, solutions, artefacts that a given project plan to deliver.
But, why defining scope is important?
At a very high level, it helps to establish common understanding of project scope among stakeholders. Referring to above conversation, both Client and Builder share common understanding about project inclusions and exclusions. Further, Council, Sub-contractors, Builder’s Admin, Surveyor, Supervisor and stack of other stakeholders will refer to same Project Scope to undertake their work.
Irrespective of nature and domain of project, Project Scope serves a common purpose.
Let us see how Project Scope documentation apply to software projects.
- Opportunity Assessment: Say, we have a vague idea (potential opportunity). We are not sure if it is worthwhile pursuing the idea. To gather more information about opportunity, we decide to invest some resources. At this stage before deploying any resources, it is important to define scope. It may be a short description of what needs focus and what not. Defining project scope will not only help to focus on right thing but also help to deploy right resources for opportunity assessment.
- Project Initiation: Often Project Board/Steering committee use Project scope to take their first major decision. That is, to initiate project. PRINCE2 methodology refers this document as ‘Project Brief’.
- Input to other documentation: Project scope is often used as an input to other project documentation like Business case, Project Plan, Request for Quote (RFQ/RFP) etc.
Now we know importance and purpose of project scope. So, how we can establish Project Scope? Depending on project complexity, political landscape, ambiguity and risk, I suggest to considering following activities:
- Understand Problem: Understand problem that project should solve. Problem can have multiple facets. It is important to understand all of them. For example, if problem is ‘bad customer service’. There can be multiple reasons for bad customer service. It can be due to poor software, lack of training, inconsistency in business processes, lack of communication etc. Understand all these different facets for given problem.
- Understand Objectives: Understand project objectives of Project sponsor and other senior stakeholders. Understand their expectations in terms of outcome of the project.
- Understand impact of problem: Analyse how problem(s) is affecting business, customers and other stakeholders.
- Understand impact of solving the problem: Analyse effect on different stakeholders as a result of project implementation.
- Understand success criteria: Establish baseline for success criteria. Success criteria is a measurement of project’s success. It can be as simple as a statement like ‘if project meets the matrices outlined in Business case then project implementation considered being a success’. Or, if project improve customer feedback by 20%. Or, if margin improve by 10% etc.
- Understand domains: Analyse which domains are within scope of the project. For example, Finance, Operations, Accounts, HR etc. Note that business domains often overlap; they have dependencies due to sharing of human resources, systems and processes. It is important to determine which business domains require to be in and out of scope of given project.
- Understand Stakeholders: Establish clear understanding about project stakeholder, their relationships with project, reporting structures. Understand formalities for approval of project deliverables. Clarify role and responsibilities.
- Understand pre-established boundaries: Identify if there are any pre-established boundaries. For example, ‘project should not allow outsourcing of any existing business function’, ‘solution options should not considered new software implementation’ etc.
- Establish boundaries: Establish new boundaries to clarify project scope.
Your next question may be where I can find Project Scope Specification template?
Well, there are thousands available on Google. You can find one I have prepared here.
I suggest following approach for documentation:
Some final tips:
Project scope specification is not Business requirements document: Project Scope document focus on what to include in scope of project. It should not include business requirements from different stakeholders.
Relevance of defining Project Scope in Scrum/Agile methodology: Irrespective of methodology, project teams must establish project scope. It does not matter if it is a separate document or part of email. Project team should decide best way to document scope. In Agile world, Project Backlog is consider as Project scope.
I hope you find this information helpful.
What about you? What is your experience in determining project scope? Which processes, tools and techniques you have used?
Share your views!