Product Scope: The features and functions that characterize a product, service, or result.
E.g. For a Radio - it could be its size, shape, weight, materials to be used, volume and channels it can tune into.
Project Scope: The work that must be performed to deliver a product, service, or result with the specified features and functions.
E.g. For a Radio - all the work that needs to be done (design, development, testing, project management, procurement, resource management, budgeting etc) to produce the Radio.
Product Scope: The features and functions that characterize a product, service, or result.
E.g. Bridge - Length, width, height, shape, load bearing capacity etc.
Project Scope: The work that must be performed to deliver a product, service, or result with the specified features and functions.
E.g. Requirement gathering, Scoping, Estimating Schedule, Estimating Cost, Identifying Risks, Identifying Stakeholders, Architecture work, Civil Engineer work, Machines utilized, Communications, Closing etc.
Simplified definitions
Requirements are "what" the customer needs. Requirements can be of many types. For example, product related requirements, performance requirements, quality requirements, project management requirements etc.
Product Scope refers to requirements that specifically relate to the "product" of the Project.
Project Scope is all the work that goes in producing the product.
Example
Let's say you have a plot of land and you want to build a house on it.
Product: The house.
Product Scope: The house should have 3 storeys, 1000 sq.m. of built-up area, 4 bedrooms with attached baths, 2 living rooms, a kitchen, a basement and a garage. The exteriors should be white.
Project Scope: Hiring a building contractor, an architect and an interior designer, acquiring legal permits, estimating the cost, taking bank loan, planning for risks such as rain and storms, designing the house, buying construction material, constructing the house, doing the interiors, buying furniture, conducting inspections, conducting regular site visits to track the progress and resolving disputes, making payments and compensations, closing contracts, and moving in.
Requirements: In addition to the Product Scope there could be other requirements for the house. Using a particular grade of cement could be your quality requirement. Making the house earth-quake proof could be a performance requirement. Getting a weekly progress update from your contractor, and making monthly payments could be your project management requirements.
================================================================
What is the difference of a project scope vs. product scope?
A project scope focuses on the various steps taken to deliver a product or service or result. Project scope can include, among other things, assembly lines, budgets, staff training, supply chains, resource allocations, reporting, meetings, stakeholder management, communications and every work needed to get the project done. Basically, it refers to anything that is needed in order to arrange the production or implementation of a product or service or result.
It does not include however the actual product/svc/result functions or features or characteristics, but rather what tools, equipment or processes will be necessary for PM to deliver the product. In this sense, project scope and product scope are tied to each other: You can’t consider product deliverable as product scope without considering the various tasks or steps needed to get to that point of project scope.
In contrast, a product scope can be defined as the features or characteristics of a product itself. Whether considering design, function or component parts, the key point is that product scope refers to the actual tangible product. In the case of a product, questions of product scope would address how it works, how it is physically made and how it can be improved in future iterations. In the case of a service, product scope focuses on the actual tasks and responsibilities of the personnel delivering the service. For example, it often suggests the ways that the service can be measured and improved for future customers or clients.
================================================================
Create a collect requirement blog - add the below to that.
SMART Requirements (alternate names parenthesis)
- Specific
- Measurable
- Attainable (Achievable, Actionable, Appropriate)
- Realistic
- Time-bound (Timely, Traceable)
Weak Requirement: The report should display all the monthly data from the marketing department
Why it is weak: Anytime you see all, always, never
and other global adjectives, beware. What if the marketing dept adds
more data; do you need to immediately update the report? What if “all
the data” that you are aware of from marketing is different than what
your customer (the report requester) perceives as “all the data”? Even
if you and the customer agree, what about a third reader?
Strong Requirement: The
report shall contain the following columns: Total Sales for Month,
Average Retail Price, Total Units Sold, Remaining Inventory, Total Cost
of Goods Sold.
It is appropriate and expected to list
every column – it might be 100 of them, but list every one exactly.
There should also be a subsequent requirement that lists what the column
headers should be as well.
Measurable: this answers whether you will be able to
verify the completion of the project. You should avoid signing up for
any requirement that cannot be verified as complete. These are
especially risky when you use non-quantitative terms (best, optimal,
fastest) for acceptance criteria.
Weak Requirement: The system shall have an optimal response time for the end-user.
Why is it weak? There is no way you can be
successful with this requirement once the new system goes into
production. It’s similar to being specific, in that optimal is not defined and really cannot be defined.
Strong Requirement: The
system shall have user response times on user click-events that are
5-seconds or less during business hours of 9AM-5PM, Mountain Time,
Monday-Friday.
Now this requirement can be measured once
the system is in production. In the first example, you might end up in a
never ending loop with the customer after the system is in production
trying to define “optimal.”
Attainable: also referred to as achievable,
actionable, or appropriate. All are fine attributes and are intended to
ensure that the requirement is physically able to be achieved given
existing circumstances. There is arguably overlap between attainable and
realistic. I generally reserve attainable to check the likelihood that I
will be able to achieve the requirement including whether the
requirement is too grandiose (which is the overlap with the term
realistic).
Weak Requirement: The
monthly marketing sales report and the monthly financial statements
shall both be delivered on the 1st business day of the month.
Why is this weak? This may not be obvious
initially and may be realized only after analysis is done. In this case
it becomes un-attainable when the project manager learns that the sales
report takes 28 hours to run, so it becomes physically impossible to
deliver these reports both on the same day with the current systems that
are available.
Strong Requirement: The
monthly marketing sales report will be delivered on the 1st business day
of the month. The monthly financial statements will be delivered on the
3rd business day of the month.
Note: The resulting strong requirement was broken into two requirements. As mentioned before, avoid using and as it can create ambiguity. Here it would arguably have been ok, but just avoid it as good practice.
Weak Requirement: The resulting web site shall be so popular that it gets 1,000,000 hits within the first week.
Why is this weak? This falls under the
grandiose category (or in some minds, realistic) and is possibly more of
a wish of the customer. Just because both parties know it’s not
achievable does not make it ok to write it down. Work with the customer
to re-write something quantitative that still captures the essence of
their goal.
Strong Requirement: The
resulting web site, when reviewed by XYZ site-rating agency, will
receive at least a 3 out 5 five rating in the category of “Fun websites
to visit.”
Realistic: answers whether the requirement is
realistic to deliver when considering other constraints of the project
and requirements. I personally reserve this category not to check for
the grandiosity or the sometimes ridiculous requirement (see
attainable), but instead look to answer whether the requirements and
other project constraints in their entirety are able to be met.
Weak Requirement: The marketing sales report will be delivered into production on or before November 1, 2008.
Why is this weak? At first glance, this is
a good requirement. The specificity of the date is good. The problem
here is after the PM analyzes the amount of work to be done and the
resources that are available to work on it, he realizes that the date is
not possible to meet. This can be addressed in several ways: adjust the
date, rephrase as hours to complete work, add additional resources to
complete the work. Once you determine the best way to address the
situation for the particular environment, re-write the requirement as
required. If additional resources are negotiated, the requirement may
not change. The important point here is to not “sign-off” on the
completed requirements until you verify that you can complete them.
Time-bound (timely, traceable): where appropriate each requirement should be time-bound or specify by when or how fast
a requirement needs to be completed or executed. In software
engineering, you may see the “T” in SMART being used to mark whether a
requirement is “traceable”, which is my opinion is a separate but
important topic in developing software. For this general requirements
overview, the focus will be on the time-bound requirement.
Weak Requirement: The report will be available soon after month-end close.
Why is it weak? Who is to say what is
“soon”? You cannon rely on what you consider to be reasonable
expectations of the customer. You may know the time cycle of month-end
close and that it takes the first 5 days of the month to complete. The
customer may assume that soon means on the 1st of the month.
Strong Requirement: The
report will be available by noon on the first business day after the
successful completion of the month-end accounting reports (insert
identifying report id).
This clearly explains to the customer when
they can expect the report (first business day, not on a weekend) and
only after a successful run of the closing monthly reports from
accounting.
This summarizes how SMART can be used to review your requirements. Requirements are an important part of setting expectations with
your customer. In the absence of facts and details, the customer will
make up assumptions in their head. State everything in your
requirements. If it is not stated, it is not committed to be completed.Once you believe you have a completed set of requirements, it is a best-practice to review them with your customers and “sign-off.” This can be done literally on paper, or electronically via email, but is a step that should not be skipped. It enforces that both parties review and completely agree on what work is being done and what is to be delivered. Do not settle for a verbal yes; people forget, change their minds, etc. By going through this formal step it helps your customer understand that you are serious about delivering what they need and to do this on-time (now defined in your requirements) and on-budget (also specified or estimated) you need a clear representation of their needs.
