3.5. Project Scope

As an Office Administrator, it’s important to know exactly what work needs to be done before starting a project. You have a team, and you need to understand what each member will do to meet the project’s goals. The first step is scope planning, which involves defining all the work needed to successfully complete the project. It’s crucial to have a clear picture of all tasks and keep this scope updated in the project’s scope management plan.

Defining the Scope

We need to refine the project’s objectives and list all the deliverables our team will produce. Deliverables are everything our project will deliver, including products, services, documents, plans, schedules, budgets, and blueprints. These deliverables are tangible outcomes or specific items that must be produced to consider the project or a project phase complete. Intermediate deliverables, like objectives, must be specific and verifiable.
All deliverables must be described in detail to differentiate them from related deliverables. For example:

• A twin-engine plane versus a single-engine plane
• A red marker versus a green marker
• A daily report versus a weekly report
• A departmental solution versus an enterprise solution

One of our main tasks is to document the project’s deliverables accurately and manage the project to produce them according to agreed criteria.

Project Requirements

After all the deliverables are identified, the project manager needs to document all the requirements of the project. Requirements describe the characteristics of the final deliverable, whether it is a product or a service. They describe the required functionality that the final deliverable must have or specific conditions the final deliverable must meet in order to satisfy the objectives of the project. A requirement is an objective that must be met. The project’s requirements, defined in the scope plan, describe what a project is supposed to accomplish and how the project is supposed to be created and implemented. Requirements answer the following questions regarding the as-is and to-be states of the business: who, what, where, when, how much, and how does a business process work?

Requirements may include attributes such as dimensions, ease of use, colour, and specific ingredients. The requirements for that deliverable may include carton design, photographs that will appear on the carton, and colour choices.

Requirements specify what the final project deliverable should look like and what it should do. Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. They can be divided into six basic categories: functional, non-functional, technical, business, user, and regulatory requirements.

Functional Requirements

Functional requirements describe the characteristics of the final deliverable in ordinary non-technical language. They should be understandable to the customers, and the customers should play a direct role in their development. Functional requirements are what you want the deliverable to do.

• Vehicle: “The vehicles should be able to carry up to a one-ton load from a warehouse to a shop.”
• Computer System: “The system should store all details of a customer’s order.”

The important point to note is that what is wanted is specified and not how it will be delivered.

Non-functional Requirements

Non-functional requirements specify criteria that can be used to judge the final product or service that your project delivers. There are restrictions or constraints to be placed on the deliverable and how to build it. Their purpose is to restrict the number of solutions that will meet a set of requirements. Using the vehicle example, the functional requirement is for a vehicle to take a load from a warehouse to a shop. Without any constraints, the solutions being offered might result in anything from a small to a large truck. Non-functional requirements can be split into two types: performance and development.  To restrict the types of solutions, you might include these performance constraints:

• The purchased trucks should be Canadian-made due to government incentives.
• The load area must be covered.
• The load area must have a height of at least 10 feet.

As mentioned earlier, projects have constraints that can be categorized according to the type of requirements. There are three general types of non-functional development constraints:

• Time: When a deliverable should be delivered
• Cost: How much money is available to develop the deliverable
• Quality: Any standards that are used to develop the deliverable, development methods, etc.

Technical Requirements

Technical requirements emerge from the functional requirements to answer the following questions: How will the problem be solved this time, and will it be solved technologically and/or procedurally? They specify how the system needs to be designed and implemented to provide the required functionality and fulfill the required operational characteristics.

For example, in a software project, the functional requirements may stipulate that a database system will be developed to allow access to financial data through a remote terminal. The corresponding technical requirements would spell out the required data elements, the language in which the database management system will be written (due to existing knowledge in-house), the hardware on which the system will run (due to existing infrastructure), telecommunication protocols that should be used, and so forth.

Business Requirements

Business requirements are the needs of the sponsoring organization, always from a management perspective. Business requirements are statements of the business rationale for the project. They are usually expressed in broad outcomes, satisfying the business needs rather than specific functions the system must perform. These requirements grow out of the vision for the product that, in turn, is driven by mission (or business) goals and objectives.

User Requirements

User requirements describe what the users need to do with the system or product. The focus is on the user experience with the system under all scenarios. These requirements are the input for the next development phases: user-interface design and system test cases design.

Regulatory Requirements

Regulatory requirements can be internal or external and are usually non-negotiable. They are the restrictions, licenses, and laws applicable to a product or business that are imposed by the government.

Measuring Requirements

Requirements Traceability Matrix

The requirements traceability matrix is a table that links requirements to their origin and traces them throughout the project life cycle. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope. This process includes, but is not limited to, tracking:

• Requirements for business needs, opportunities, goals, and objectives
• Requirements for project objectives
• Requirements for project scope/work breakdown structure deliverables
• Requirements for product design
• Requirements for product development
• Requirements for test strategy and test scenarios
• High-level requirements to more detailed requirements

Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about the requirement. Typical attributes used in the requirements traceability matrix may include a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved), and date completed. Additional attributes to ensure that the requirement has met stakeholders’ satisfaction may include stability, complexity, and acceptance criteria.

“4.5. Project Scope” from Essentials of Project Management by Adam Farag is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License, except where otherwise noted.