Project Scope and Requirements

Introduction

Source: Adam Farag, https://ecampusontario.pressbooks.pub/essentialsofprojectmanagement/chapter/4-1-chapter-introduction/
This work is licensed under a Creative Commons Attribution 4.0 License.

Strategic Alignment

The project initiation phase is the first phase within the project management life cycle, as it involves starting up a new project. Within the initiation phase, the business problem or opportunity is identified, a solution is defined, a project is formed, and a project team is appointed to build and deliver the solution to the customer. A business case/proposal (sometimes called a feasibility study) is created to define the problem or opportunity in detail and identify a preferred solution for implementation. The business case/proposal includes:

• A detailed description of the problem or opportunity with headings such as Introduction, Business Objectives, Problem/Opportunity Statement, Assumptions, and Constraints
• A list of the alternative solutions available
• An analysis of the business benefits, costs, risks, and issues
• A description of the preferred solution
• Main project requirements
• A summarized plan for implementation that includes a schedule and financial analysis

SMART Project Objectives

In the early 1980s, George T. Doran introduced the SMART set of criteria for projects, goals and objectives. SMART is an acronym for Specific, Measurable, Assignable, Realistic, and Time-Related. The smart criteria have been applied in many different areas of management, including project management. Let's take a look at each of Doran's criteria as they apply to project management.

Specific – A project needs to be specific about what it will accomplish. Unlike many organizational goals, the goal of a project should not be vague or nebulous. An organization may want to "make London, Ontario a great place to live," but its projects need to focus on a specific goal. For example, a more specific goal would be to build a downtown farmers' market. A project that is specific is one that can be clearly communicated to all team members and stakeholders. A specific project goal will answer the five 'W' questions:

1. What do we want to accomplish?
2. Why are we undertaking this project?
3. Who is involved or will be affected by the project?
4. Where will this project be conducted?
5. Which constraints (scope, time, money, risk, etc.) have been placed on our project?

Measurable – How will project progress and success be measured? What will be the measurable difference once our project is completed successfully? These measures should be quantifiable.

Assignable – Who will do the work? Can people be identified who have the expertise in the organization to complete this work? Or can the expertise be hired from outside of the organization?

Realistic – Is it realistic that the organization can achieve this project, given its talents and resources? This is a very important consideration for businesses of all sizes. Yes, it would be great to produce a new driverless car, but is that realistic given the resources that the organization has available?

Time-related – when will the project be completed and how long will it take? These criteria can be very useful when defining a project. If the description for a project does not meet all these criteria, then it is time to go back to the drawing board and make sure that what is being described is really a project, rather than a program or strategic goal.

For example, an objective of the team principal (project manager) of a Formula 1 racing team may be that their star driver, "finish the lap as fast as possible." That objective is filled with ambiguity.

How fast is "fast as possible?" Does that mean the fastest lap time (the time to complete one lap) or does it mean the fastest speed as the car crosses the start/finish line (that is at the finish of the lap)?

When should the driver be able to achieve the objective? It is no use having the fastest lap after the race has finished, and equally the fastest lap does not count for qualifying and therefore starting position, if it is performed during a practice session.

The ambiguity of this objective can be seen in the following example. Ferrari's Michael Schumacher achieved the race lap record at the Circuit de Monaco of 1 min 14.439 sec in 2004 (Figure 4.1). However, he achieved this on lap 23 of the race but crashed on lap 44 of a 77-lap race. While he achieved the fastest lap and therefore met the specific project goal of "finish the lap as fast as possible," it did not result in winning the race, clearly a different project goal. In contrast, the fastest qualifying time at the same event was by Renault's Jarno Trulli (1 min 13.985 sec), which gained him pole position for the race, which he went on to win (Figure 4.1). In his case, he achieved the specific project goal of "finish the lap as fast as possible," but also the larger goal of winning the race.

The objective can be strengthened considerably if it is stated as follows: "To be able to finish the 3.340 km lap at the Circuit de Monaco at the Monaco Grand Prix in 1 min 14.902 sec or less, during qualifying on May 23, 2009". This was the project objective achieved by Brawn GP's Jenson Button.

Financial Considerations

In many new project endeavours, we need to find out if our project is financially feasible. We do that by using net present value (NPV), rate of return (ROI), and payback analysis, as will be discussed later in chapters 6 and 10.

Weighted Decision Matrix

A weighted decision matrix is a decision tool used by decision-makers.

A decision matrix is basically an array presenting on one axis a list of alternatives, also called options or solutions. On the other axis, is a list of criteria, which are weighted depending on their respective importance in the final decision to be taken.

The example in Figure 4.2 shows a weighted decision matrix that compared three options for a web development project (SJS Enterprises). This method is especially useful when choosing purchase alternatives and comparing them against specific desirable system requirements.

Sometimes we have multiple options to choose from when determining requirements and deciding which project to work on. To select the best option, we can use tools such as a weighted decision matrix.

A basic decision matrix consists of establishing a set of criteria for options that are scored and summed to gain a total score that can then be ranked. Importantly, it is not weighted to allow a quick selection process.

A weighted decision matrix operates in the same way as the basic decision matrix but introduces the concept of weighting the criteria in order of importance. The resultant scores better reflect the importance to the decision maker of the criteria involved. The more important a criterion, the higher the weighting it should be given. Each of the potential options is scored and then multiplied by the weighting given to each of the criteria to produce a result.

The advantage of the weighted decision matrix is that subjective opinions about one alternative versus another can be made more objective. Another advantage of this method is that sensitivity studies can be performed. An example of this might be to see how much your opinion would have to change in order for a lower-ranked alternative to outrank a competing alternative.

A weighted decision matrix therefore allows decision-makers to structure and solve their problems by:

1. Specifying and prioritizing their needs with a list of criteria; then
2. Evaluating, rating, and comparing the different solutions; and
3. Selecting the best matching solution.

Project Charter

What is the Project Charter?

A project charter, project definition, or project statement is a statement of the scope, objectives, and participants in a project. It provides a preliminary delineation of roles and responsibilities, outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager. It serves as a reference of authority for the future of the project.

The charter document can be just a couple of pages in length or can be 50-100 pages. Ideally, it will be short (less than 5 pages) and written in clear and concise language so that anyone who reads it will have a clear understanding of the project, regardless of their technical background. Most project charters include a place at the end of the document for approval sign-off by the project sponsors or customers (i.e. those people who are paying for the project).

Purpose of the Project Charter

The project charter is used by the project manager during the planning process. The project charter informs the project manager about what skills will be required on the project team, as well as the general scope of work for the project. Some organizations forgo the creation of a project charter, viewing it as a document that merely takes time to create and contains information that "everyone already knows". This can be a big mistake. The charter can be referenced by the project manager and stakeholders if some of the goals of the project are not met or they are asked to do something outside the scope of the project. A well-drafted project charter can prevent political interference in achieving the goals of the project and reduce scope creep.

In summary, the purpose of a project charter is to:

• Provide an understanding of the project, the reason it is being conducted, and its justification.
• Establish early on in the project the general scope.
• Establish the project manager and his or her authority level. A note of who will review and approve the project charter must be included.

What Should Be in the Project Charter?

There are many templates available for project charters and these vary greatly in the content and level of detail. (The PMI affiliated website ProjectManagement.com offers a number of project charter templates) At a minimum, good project charters will contain the following sections.

Background

The background should provide a broad overview of the project and answer the following questions:

• What is the purpose of the project?
• Where did the project originate? Have we conducted similar projects in the past?
• Who is the project manager and what level of authority does the project manager have?

Business Case

The Business Case describes why this project was selected over others and answers the following questions:

• Why was this project selected to move forward (project justification)? What selection criteria were used? (Project selection techniques are covered in a later chapter.)
• What problems is this project solving or what opportunities is it creating? What are the high-level requirements?

Goals

Listing the goals for the project ensures that the stakeholders will not be disappointed when the project is completed. This section should answer the following questions:

• What are the broad goals of this project?
• How will we know if the project is a success (what are our metrics for success)?
• Are there industry standards that we are trying to meet or benchmarks for performance that we want this project to attain?

Key Stakeholders

This section describes the key stakeholders and their interest in the project. This doesn’t have to be an exhaustive list of stakeholders, but should contain a list of people who are interested in the project, as well as people who will pay for, or benefit from, the project.

Deliverables

A project is said to have deliverables as products or services. They are things such as physical objects, software code, or events that make up the project and they are written in the form of nouns, for example, floor, walls, electrical…etc.

Major Milestones

This section provides a summary of the major milestones for the project. A listing of any hard deadlines for the project should be included. Milestones can relate to project work (when are major deliverables expected to be complete?) as well as invoicing and payment deadlines.

Project Budget

The project budget section should provide a summary of the budget for the project and information about how it was determined. It answers the following questions:

• What is the initial budget for this project?
• How was that budget developed?
• Are the numbers used for budgeting rough estimates based on top-down estimation techniques, such as analogous or parametric estimating, or are they hard constraints?
• What contingency funds have been allocated?

Project Scope

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

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.

All deliverables must be described in a sufficient level of detail so that they can be differentiated 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 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, colour, 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.

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 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.

As mentioned earlier in Chapter 1, 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 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.

Managing the Scope

Time, cost, and scope are known as the triple constraints of project management. It's not possible to change one without changing at least one of the others. If the project takes twice as long as expected to complete, then the cost will almost certainly go up. On the other hand, a decision to cut costs, perhaps by using less experienced labour, could lead to a work slowdown, extending the schedule. Such a decision might also result in a change to the project's scope, perhaps in the form of a lower-quality product.

The initiation phase is too early in the project to nail down precise details about time and cost, but it is a good time to think long and hard about scope, which is "all of the work that needs to be done to provide the product or service your project is delivering" (Martinez, n.d.). In this early stage, you and the project stakeholders might do some blue-sky thinking about what your project could possibly achieve, without regard to the constraints of time, cost, and scope. But before too long you'll need to zero in on a definition of the project's scope, formalizing it as a scope statement, using the information currently available to you.

Except for the simplest projects, any scope definition will almost certainly evolve as you learn more about the project and the customer's needs. The term scope evolution refers to changes that all stakeholders agree on, and that are accompanied by corresponding changes in budget and schedule. Scope evolution is a natural result of the kind of learning that goes on as a project unfolds. This includes learning that arises from fresh insights into the needs of the end user, new regulations, or upheaval in the marketplace. As long as all stakeholders agree on the scope changes (and the associated changes to the budget and schedule), scope evolution ensures that customers actually get what they want out of the project. The more you talk with the client and learn about their needs, the more you will be able to refine the scope.

Indeed, one of the main jobs of a project manager is managing scope evolution. However different types of projects will involve varying amounts of scope evolution. For example, if you're working on a project related to satisfying a specific environmental regulation, the initial definition of the project's scope might be clear, requiring little refinement as the project unfolds, as long as the regulation itself is not altered. But if you are working on a product designed to satisfy a brand-new market demand, you might need to refine the scope continually to ensure that you satisfy your customers' needs.

Perhaps the most common cause of scope evolution is a change in the context in which a project is planned and executed. Alterations in market forces, changing demographics, new or more vigorous competition, and technological advancements can all change a project's context, forcing you to rethink its scope. This potential for changing contexts means that no two projects are the same.

Scope evolution is managed change. It is an approved alteration to the project scope that occurs as the project participants learn more about the project. It results in an official change in the project scope, and therefore to the project budget or schedule, as agreed to by all project participants. This kind of managed change is a natural and rational result of the kind of learning that goes on throughout the course of a project. It is a conscious choice necessitated by new information forcing you to reconsider project essentials in order to achieve the intended project value.

Scope creep is unmanaged change. It is caused by uncontrolled changes to the project scope. Such changes might add value from the customer's perspective, but the time, money, and resources consumed by the change of scope lead to additional overruns. Scope creep tends to happen bit by bit because no one is paying close attention to the project's scope. For example, in a kitchen remodelling project intended to replace countertops and cabinets, deciding at the last minute to replace all appliances might be an example of scope creep.

Creating a Clear Scope Statement

The key to managing scope is a carefully crafted scope statement, which should be clear and precise. The details of how you plan to carry out a project may be vague at first, but what you want to achieve should be perfectly clear. Vagueness can lead to small changes to the project's scope, which in turn lead to other changes until the original project is no longer recognizable.

Writing a scope statement, the document that defines the project's scope is a major part of the initiation phase. However, according to Brad Bigelow in an article for the Project Management Institute, it is "usually expressed in qualitative terms that leave room for interpretation and misunderstanding. Consequently, it's often the biggest source of conflicts in a project".

To avoid such problems, experienced project managers put a lot of effort into learning what should and shouldn't be included in the project, and then articulating these boundaries as clearly as possible in the form of a scope statement. According to Bigelow, this work is essential to ensuring a project's success: "No project's scope can ever be entirely free of fuzziness - free from subjectivity and imperfect definitions - as long as human beings are involved. On the other hand, it's also highly improbable that any project will ever survive initiation if its scope is entirely vague, undefined, and subject to unpredictable expectations".

If the scope is poorly defined, then what is or isn't within the project scope is reduced to a matter of perspective. Not surprisingly, these "different perspectives…can often be the root of conflicts within a project" Bigelow. Bigelow describes a project in which the team and the customer see things very differently:

When the scope is poorly defined, satisfying the customer can grow increasingly difficult, with the team going off and creating what it thinks the customer wants, only to be told, "No, that's not it".

Opinions vary on exactly what a scope statement should include, but at the very least it should contain the following:

• A brief justification of the project's purpose, including a summary of the business needs the project will address.
• An explanation of the project's goals.
• Acceptance criteria specify the conditions the product or service must satisfy before the customer will accept the deliverables.
• Deliverables are "the quantifiable goods or services that will be provided upon the completion of a project. Deliverables can be tangible or intangible parts of the development process, and they are often specified functions or characteristics of the project".
• An explanation of anything excluded from the project - in other words, an explanation of what is out of scope for the project. This list should be "as detailed as is necessary to define the project boundaries to all stakeholders".
• Constraints, such as budget and schedule.
• Assumptions, including anything you currently believe to be true about the project. It's also helpful to include ideas "about how you will address uncertain information as you conceive, plan, and perform your project".
• An explanation of any new or unusual technology you plan to use throughout the project. This is not a typical part of a scope statement, but "it's likely that stakeholders will appreciate the transparency and feel more comfortable with the project moving forward".

Practical Tips

• Engage all stakeholders: Your goal is to keep people meaningfully engaged in your project. You don't want stakeholders showing up for ceremonial appearances at project meetings. Instead, you want them seriously focused on the prospects for project success.
• Outcome clarity: Ask your customer to define success right at the beginning. Then, working with the customer and other stakeholders, define how success will be measured.
• Use a common vocabulary: At the beginning of any project, go to your end customers and learn their vocabulary. Make sure you understand the terms that are important to them and what such terms mean to them. Whenever possible, use your customer's vocabulary, not yours. Also, strive to speak in plain English whenever you can, and avoid techno-speak.
• Create a glossary of terms: On projects with a lot of complex jargon, consider creating a glossary of terms. Then publish it in a way that makes it accessible to all stakeholders, updating it as needed. Here's an example of one such glossary: "COSO Framework ".
• Identify what you don't know: When you start a project, there are always things you don't know. The key is to know that you don't know them. The more you strive to recognize this, the better you will be at predicting those unknowns and making provisions for them.
• Have key team members sign major project documents: Research shows that the act of signing a document makes people much more committed to delivering on the promises described in the document. Consider asking the entire project team to sign the project charter and scope documents. This simple act can serve as a powerful inducement to complete the project successfully.
• Proactive concurrency: In the early stages, avoid the trap of plotting one thing after another, in a linear fashion. Instead, start fast, doing as many things as you can concurrently, as quickly as you can. This will give you a sense of whether or not the scope, budget, resources, and schedule are all in relatively close alignment at the macro scale. If you find they are not, report that to management right away.
• Permanent urgency: In the living order in which all modern projects unfold, permanent urgency is the new law of nature. In the traditional, geometric order form of project management, you could assume that you would have sufficient time and resources to do things in a linear, step-by-step manner. But in the modern world, that's rarely the case. Get used to an element of urgency in all projects. Try not to let this paralyze you and your team. Instead, let a sense of urgency spur you on to more agile, alert, and flexible project management techniques.
• Post the project documents prominently: Putting important documents front and centre helps a team stay focused, especially if you have everyone sign them first. It also encourages the team to update them when necessary.
• Plan for errors: You and your team will almost certainly make mistakes, especially in the early stages of a project. Therefore, you should plan for that. Keep thinking ahead to what might go wrong, and how you could correct course.

Business Case (In-class discussion)

Simple Example of a Project Charter

Identification Section

List the project name, the date of the current version of the project charter, the sponsor's name and authority, and the project manager's name.

Example:

Project Name: Rice University Computer Store Creation

Project Sponsor: Jane Ungam, Facilities Manager

Date: Jan 12, 2010

Revision: 1

Project Manager: Fred Rubens

Overview of the Project

Provide a simple but precise statement of the project.

Example: Rice University is planning to create a store to sell computer supplies.

Objective

State the objectives of the project clearly and ensure they contain a measure of how to assess whether they have been achieved. The statement should be realistic and should follow the SMART protocol:

• Specific (get into the details)
• Measurable (use quantitative language so that you know when you are finished)
• Acceptable (to stakeholders)
• Realistic (given project constraints)
• Time-based (deadlines, not durations)

Example: The objective of this project is to implement a campus store when class starts in August 2010 with enough inventory (computer supplies, such as memory sticks, mouse pads, and cables) to last through the first two weeks of classes.

Scope

Specify the scope of the project by identifying the domain or range of requirements.

Example: The scope of the Rice's school supplies store project includes the activities listed below:

1. Determine what supplies will be sold in the store.
2. Establish competitive prices for the computer supplies.
3. Source and secure supply vendors.
4. Establish marketing, procurement, operations, and any other necessary departments, schools, centres, and institutes

It is equally important to include in the scope what is not included in the project.

Example: The scope of the project does not include:

• Development of any other school store departments
• Store design or construction

Major Milestones

List all major milestones needed to ensure project completion successfully.

Example:

• All vendors selected
• Contracts or orders completed with all vendors
• Supplies delivered to the store
• Pricing determined

Major Deliverables

List and describe the major deliverables that will result from the project.

Example:

• Operations, procurement, marketing, and other teams established
• Store supplies stocked and displayed
• Store staffing completed, including work schedules
• Store operations policies, including hours of operation, established

Assumptions

Outline the assumptions made in creating the project. An assumption is a fact you are unsure of but can either confirm at a later time or are simply stating so that the project can proceed as if the statement were true.

Example:

• Only computer supplies will be sold in the store.
• Customers will be the Rice University student body and faculty.
• Rice University students will manage the project and be responsible for ongoing operations.
• A store sponsor from the university faculty or staff will be assigned to mentor students and provide oversight.
• Store hours of operation will be approved by the Rice University students or store sponsor.
• Supplier deliveries will be arranged or the store sponsor will pick them up with students.
• Students will be empowered to contact vendors for order placement and inquiries via telephone.

Constraints

Define any and all constraints on the project or those working on the project. This is an important part of the project charter. A constraint is anything that limits the range of solutions or approaches.

Example:

• Student availability to meet for project planning is limited to school hours.
• Software is not available for project planning and control.

Business Need or Opportunity (Benefits)

Provide a concise statement of the business need or opportunity that led to the creation of the project. Why was it created? What are the benefits? How does the project contribute to organizational objectives?

Example: The goal of this project is to provide income for the Rice Student Center while supplying necessary items to students and faculty at competitive prices. The school store will be a convenience to students since necessary supplies will be available on campus. This will help students learn to manage their personal supplies.

Preliminary Cost for the Project

Provide a statement indicating how the cost of the project will be defined and controlled.

Example: The procurement team will assemble a proposal based on expected costs for review by the Dean of Undergraduate Studies.

Project Risks

A risk is anything uncertain that may occur that will reduce or decrease the chances of project success.

Example:

1. There is a state election coming and the new government may change the taxation rules for private university retail outlets.
2. The cloud is changing student demand for media such as flash drives in somewhat unpredictable ways. If this happens faster than we forecast, we may be building a store that students don't need.
3. Deliveries of items, such as store shelves, will be delayed if a major hurricane occurs.

Project Charter Acceptance

Provide the names, titles, and signature lines of the individuals who will sign off on the project charter.

Project Stakeholders

Provide the key stakeholders and team members by function, name, and role

Key Terms

• Assignable: Who will do the work? Can people be identified who have the expertise in the organization to complete this work? Or can the expertise be hired from outside of the organization?
• Business Requirements: The needs of the sponsoring organization, always from a management perspective. Business requirements are statements of the business rationale for the project.
• 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.
• Non-Functional Requirements: Specify criteria that can be used to judge the final product or service that your project delivers.
• Project Charter: project definition or project statement is a statement of the scope, objectives, and participants in a project. It provides a preliminary delineation of roles and responsibilities, outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager.
• Project Scope Planning: 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.
• Realistic: Is it realistic that the organization can achieve this project, given its talents and resources? This is a very important consideration for businesses of all sizes. Yes, it would be great to produce a new driverless car, but is that realistic given the resources that the organization has available?
• Regulatory Requirements: These 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.
• Scope Evolution: Refers to changes that all stakeholders agree on, and that are accompanied by corresponding changes in budget and schedule. Scope evolution is a natural result of the kind of learning that goes on as a project unfolds.
• Scope Statement:  The document that defines the project's scope, is a major part of the initiation phase.
• SMART: An acronym for Specific, Measurable, Assignable, Realistic, and Time-Related. The smart criteria have been applied in many different areas of management, including project management. Let's take a look at each of Doran's criteria as they apply to project management.
• Specific: A project needs to be specific about what it will accomplish. Unlike many organizational goals, the goal of a project should not be vague or nebulous.
• 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.
• Time-Related: When will the project be completed and how long will it take? These criteria can be very useful when defining a project. If the description for a project does not meet all these criteria, then it is time to go back to the drawing board and make sure that what is being described is really a project, rather than a program or strategic goal.
• 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.
• Weighted decision matrix: A decision matrix is basically an array presenting on one axis a list of alternatives, also called options or solutions. On the other axis is a list of criteria, which are weighted depending on their respective importance in the final decision to be taken.