Chapter 5 – Project Life Cycle, Scope, Charters, Proposals
5.9. Project Scope
After looking at the 4 phases of the Life Cycle of a project, we will move to the Project Scope that is designed at the beginning of the project.
You always want to know exactly what work has to be done before you start it. You have a collection of team members, and you need to know exactly what they’re going to do to meet the project’s objectives. The scope planning process is the very first thing you do to manage your scope. Project scope planning is concerned with the definition of all the work needed to successfully meet the project objectives. The whole idea here is that when you start the project, you need to have a clear picture of all the work that needs to happen on your project, and as the project progresses, you need to keep that scope up to date and documented in the project’s scope management plan.
Defining the Scope
The Scope is the work that needs to be completed to deliver the product/service. It is the final result of the project. In simple terms, the Scope Statement includes Who? What? When? Where? Why? Costs.
Example of a simple Scope Statement:
A party is planned for my parents on September 15th, 2022 from 6:00 p.m.- 12:00 p.m. at the ABC Community Centre for their anniversary at a cost of $2,000.00 There will be a dinner and a band.
Deliverables
You already have a head start on refining the project’s objectives in quantifiable terms, but now you need to plan further and write down all the intermediate and final deliverables that you and your team will produce over the course of the project. Deliverables include everything that you and your team produce for the project (i.e., anything that your project will deliver). The deliverables for your project include all of the products or services that you and your team are performing for the client, customer, or sponsor. They include every intermediate document, plan, schedule, budget, blueprint, and anything else that will be made along the way, including all of the project management documents you put together.
Project deliverables are tangible outcomes, measurable results, or specific items that must be produced to consider either the project or the project phase completed. Intermediate deliverables, like the objectives, must be specific and verifiable.
Deliverables can be simply stated in project documents. The are the final output along the way of completing the project. Some example may include:
- Designing the product
- Reporting progress
- Complete content strategy
- Proposal written
- Technical support
- Financial Reporting
- Communication Plan
- Product prototype development
One of the project manager’s primary functions is to accurately document the deliverables of the project and then manage the project so that they are produced according to the agreed-on criteria. Deliverables are the output of each development phase, described in a quantifiable way.
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, color, and specific ingredients. If we go back to the example of the company producing holiday eggnog, one of the major deliverables is the cartons that hold the eggnog. 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 Example: If you were buying vehicles for a business, your functional requirement might be: “The vehicles should be able to take up to a one-ton load from a warehouse to a shop.”
Computer System Example: For a computer system you may define what the system is to do: “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.
Other examples include:
- Business rules
- Tracking audit
- Certification requirements
- Levels of authorization for project
Non-functional Requirements
Non-functional requirements specify criteria that can be used to judge the final product or service that your project delivers. They 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 American-made trucks due to government incentives.
- The load area must be covered.
- The load area must have a height of at least 10 feet.
Projects have constraints that can be categorized according to 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 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 required functionality and fulfill 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.
Other examples:
- Software availability
- Security of information
- Internal controls
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.
Examples include:
- Accurate monthly reporting
- Consistent data produced
- Complete surveys and questionnaires for the accuracy of information
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.
- Software needs to allow 500 users access simultaneously
- Adequate internet speed
- Software must have ease of use for users
- Data collected needs to be tracked that is consistent
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. They required compliance for all, and standards must be met.
