Product_Specifications_and_Features_2025Spring_v1.pptx

product spec

1. Project Specifications and Features February 10, 2025 Michelle Narciso, PMP Consultant Chuck Duey Keysight Steve Narciso Keysight 1

2. Objectives and Background Objectives: Create Product Specification: Outline key features that contribute to the value proposition of your product/system Understand strategies for effectively communicating the value proposition to potential customers and auxiliary members of the project outside the design team (marketing, manufacturing, product support, etc ) List the items of the risk evaluation for your product/system First pass on how to test your product/system (verify requirements) 2 Background: The content includes concepts from Keysight requirements management material The Project Management Institute (PMI) Coventry, T. (2015). Requirements management – planning for success!: techniques to get it right when planning requirements. Paper presented at PMI® Global Congress 2015—EMEA, London, England. Newtown Square, PA: Project Management Institute.

3. What defines project success? How do you think that can be achieved? Discussion Topic 3

4. All of the top factors found in failed projects include: Incomplete Requirements Lack of user involvement Lack of resources Unrealistic expectations Lack of executive support Changing Requirements & Specifications Lack of planning Didn’t need it any longer Lack of IT management Technical illiteracy The top five indicators found in challenged projects are: Lack of user input Incomplete Requirements & Specifications Changing Requirements & Specifications Lack of executive support Technical incompetence The top five factors found in successful projects are: User involvement Executive management support Clear Statement of Requirements Proper planning Realistic expectations Analysis – Standish Group 2019 Why is defining spec and features important? Taken from https://www.opendoorerp.com/the-standish-group-report-83-9-of-it-projects-partially-or-completely-fail/ 4

5. 5 Strong communication is key to project success

6. Example Product Features Used to Attract Customers 6

7. Definition Review & Introduction Project Project Manager Project Lifecycle Requirements Management 7

8. Definition of a Project A project is a set of related activities undertaken to create a unique product or service, constrained by time, cost and other factors. Project characteristics: Organized set of activities beginning and an end defined budget generates deliverables draws on a number of resources 8 A project is a unique effort with a defined beginning , a defined end , a specific deliverable and defined resources . Schedule Scope Resource

9. What is a Project Manager? An individual who organizes, plans, and executes projects within defined constraints Their goal is to: Complete a project on time Complete a project within budget Manage risks to avoid impacts on execution Deliver something that meets their business and customer’s needs 9

10. Project Lifecycle The phases that make up the path that takes your project from the beginning to the end. Contain clearly defined checkpoints (with entry/exit criteria) which may include: Conducting a review Delivering hardware, software, or a document Conducting a Test 10 Initiation Planning Execution Closeout Project Definition Identify risks & quality standards Develop initial project plan Refine scope/ requirements Assess risks and define quality procedures Refine project plan Manage project scope Monitor and control risks and quality Manage project execution Assess project performance Identify lessons learned Archive information

11. Requirements Management Requirements management is the process of gathering, documenting, analyzing, and prioritizing the needs and requirements for a project Goal: Focuses on WHAT’s to be done Controls change Validates results The process: Details activities and deliverables for managing requirements Tailorable for projects to provide “just enough” level of process to help get the job done Standardizes on document names and TOP LEVEL content Provides framework for cross-organization/cross functional working Integrated with the Project Management processes 11 Initiation Planning Execution Closeout Detailed Design Acceptance Testing Sub-system testing System Integration System Testing User Requirements System Requirements Architectural Design Verification & Validation Project Definition Project Test & Integration Decomposition

12. Creating Product Specs & Features Gathering Information Documenting Requirements Assessing Requirements Risk evaluation Verification approach (Analysis, Test, Demonstration, Inspect) 12

13. How could you gather information about a product? Discussion Topic 13

14. Understand the competition What exists today and what makes your product different/better Understanding potential customers Who might be interested in the product (are there multiple applications) Factors that would limit potential market (cost, lead time, etc ) Conduct meetings Ask potential customers for necessary vs. desired features (If you can’t do something now you can roadmap a path to increase capabilities later) Survey potential customers Leverage non-biased surveys Market Research Gathering Information Before development begins Customer Interviews / Focus Groups Questionnaires and Surveys (Good survey tips: https://delighted.com/blog/creating-surveys ) Storyboard GUI Mock-up Breadboards Prototypes 14

15. Non-biased surveys ask questions in a way that doesn’t lead the respondent to reflect true opinions and experiences. Neutral language Leverage facts Make clear questions and answer options Make anonymous Surveys Gathering Information 15

16. Surveys: Example Gathering Information What is wrong with the following questions? How awesome is the product? Where do you enjoy drinking coffee? Was the product easy to find and did you buy it? Did the product help you meet your OKRs? Was the facility not unclean? 16

17. Surveys: Example Answers Gathering Information What is wrong with the following questions? How awesome is the product? Leading question; possibl e solution “How would you rate this product?” Where do you enjoy drinking coffee ? Required qualifying information: That the customer drinks coffee Was the product easy to find and did you buy it? Double-barreled product question: Did the product help you meet your OKRs ? Product question with jargon (OKR = Objective and Key Results); possible solution “Did the product help you meet your goals?” Was the facility not unclean ? Double-negative; possible solutions “How would you rate the cleanliness of the facility?” 17

18. Unique Differentiators should be difficult to achieve – otherwise, why do the project? The differentiators are characteristics that are unique, valuable and proven by launch. Unique: outperforms competitive offerings Valuable: it has economic impact and value for your customer Proven: evidence of how/why this capability consistently outperforms the competition exists. Unique Differentiators are the product’s unique and compelling contribution to the customer, which remains unchanged throughout the project and without which the product will fail in the marketplace. They should differentiate the product from all other products, remain stable from concept to capacity, and serve as the basis for all project trade-off decisions. They are used to: define and focus the product development project; manage the project, as the ongoing driver for the project the basis for all decisions involving project trade-offs. Example? Product Unique Differentiators Define the Project - Key Concepts 18

19. A ‘good’ requirement is: Necessary Verifiable Attainable Clear ( Unambiguous, complete, expressing a single thought) What to Include Documenting Requirements 19

20. Using incorrect sentence structure/bad grammar Missing requirements Use a checklist such as ‘FLURPS” Over-specifying – it has been reported that: 45% features NOT used 19% features RARELY used 16% features SOMETIMES used 20% features OFTEN used Requirement Pitfalls Documenting Requirements Pitfalls in Requirements: Making bad assumptions (insufficient info, document assumptions) Writing implementation instead of requirements (ask why?) Describing operations instead of writing requirements Using incorrect terms Requirements use ‘shall’ Statement of fact use ‘will’ Goals use ‘should’ Don’t use ‘support’; ‘But not limited to’; ‘etc.’; ‘And/or’ 20

21. Example Documenting Requirements What is wrong with the following requirements? The user-interface shall be easy to use. The system shall support the training coordinator in defining training scenarios. Ha ve a unit calibration time commensurate with equivalent products. The system’s power sensors will operate over various power and frequency ranges. The ability for customer to download firmware on-site is required so that new features etc. can be added as they become available. Minimize specified test equipment required to calibrate unit. The system (mobile test set) shall be capable of being connected to a mobile phone. 21

22. Example Answers Documenting Requirements What is wrong with the following requirements? The user-interface shall be easy to use . The system shall support the training coordinator in defining training scenarios. Ha ve a unit calibration time commensurate with equivalent products. The system’s power sensors will operate over various power and frequency ranges. The ability for customer to download firmware on-site is required so that new features etc . can be added as they become available. Minimize specified test equipment required to calibrate unit. The system (mobile test set) shall be capable of being connected to a mobile phone. This was a missing requirement from an actual product! 22

23. All requirements should be verifiable by one or more of the following: Analysis -  verification of a product or system using models, calculations and testing equipment Test - verification of a product or system using a controlled/predefined input to a product or system that produces a predefined output Demonstration – operation of a product or system as it is intended to be used to verify that the results are as expected Inspection - examination of a product, system, or document to show intended performance/results Verification and Validation Evaluating Requirements Detailed Design Acceptance Testing Sub-system testing System Integration System Testing User Requirements System Requirements Architectural Design Verification & Validation 23

24. Requirements should be assessed for potential risks by evaluating: Severity of risk Likelihood of occurrence Mitigation strategies Typically risk is managed/documented within a risk & opportunity matrix Assessing Risk Evaluating Requirements Errors left here… …often don’t get found until here Cheap to fix Costly to fix High 5 4 1 3 4 2 3 2 Low 1 Low 1 2 3 4 High 5 Consequence Likelihood

25. Conduct Requirements Review periodically to determine Are requirements uniquely identified? (specifically important to managing customer requirements vs internal requirements) Is the rationale for each requirement described? Are each product development element traceable to requirements? Feedback from key stakeholders Review examples Kickoff Systems Requirements Review (SRR) Preliminary Design Review (PDR) Critical Design Review (CDR) Acceptance Conduct reviews Requirements Management 25

26. Evolution Requirements are as likely to be removed as added Objective is to provide customer value not make the product bullet proof against anything a competitor might add Changes occur before much is invested in the changed requirement Baseline A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development and that can be changed only through formal change control procedures. Scope Creep Requirements are added and schedule and resource remains the same – but it can’t remain the same Change management Requirements Management 26

27. Customer feedback Market Validation Discovery vs Validation Discovery for low confidence areas vs. validation for high confidence areas Be open to discovery of customer needs/tasks/problems Be prepared for invalidation of concepts/next bench/prototypes Be sure to validate assumptions/alternatives/designs prior to the test phase 27

28. Customer feedback Market Validation Customer Feedback Pitfalls Expert Customers can teach you lots about your products and their deficiencies however they are not typical are willing to put up with shortcomings and cope with workarounds that would bring many complaints from mainstream customers can obscure deficiencies in your products Customers seldom know what they want. Internal customers can confuse you (“Customers define value. Other Stakeholders define constraints” Jim Highsmith) 28

29. Feature What Currently Exists Price Point (& Source) Is this verifiable? 1 Electric Oral - B $41.98 (Amazon) Yes Philips $34.49 (Amazon) Yes 2 3 Research market Document end design features Specify in writing what you believe the customer wants How does the market research align Guideline The Assignment Optional Focus for this week