Unit 05 - Project Definition and Requirements

1. Unit 05 - Project Definition and Requirements Sectional slide

2. Agenda Unit 5: Project Definition and Requirements • Objectives • Project requirements • Scope definition • Specification questions • Project definition and requirements: organizing for results • Key Messages - Unit 5

3. Objectives At the end of this module, you will be able to - • Recognize the need to validate requirements • Recognize pitfalls in defining requirement • Describe how to define a requirements baseline • Prepare a scope definition document for effective project planning

4. The Basic Project Definition Questions The first step in the project definition process is to address the following questions: • Precisely who is affected by the project? • What are the requirements of those affected? • Who is involved in the delivery of work? • Where are we now? • Where should we end up?

5. The Basic Project Definition Questions The first step in the project definition process is to address the following questions, continued: • What are the technical performance requirements? • What are the expense limitations? • What is the project's duration including time-to-market, time-to-profitability, and total life cycle? • What are the risks? • What are most important aspects of deliverables, that is, technical, ease of use, distribution?

6. Differences between Goals, Objectives, Requirements, and Specifications Ends that the firm strives to attain - e.g., becoming the leader in indoor mall transit systems Specific targets that further the goal - e.g., implementing a new mall transit system for the Wickedgood Shopping Mall in Bar Harbor, Maine, within budget, to be operational by September 1. The needs of the customer that refine the objectives in sufficient detail to plan the work The firm's approach to meeting the requirements, goals, and objectives, spelled out in considerable detail Goals Objectives “What” Requirements Specifications

7. Project Objectives • Establish unambiguous and realistic objectives • Good objectives are unambiguously stated and contain a measure of how to assess whether or not they have been achieved • To be realistic, objectives must be determined jointly by project managers, functional managers, and those who perform the work - a top-down, bottom-up process • Periodically evaluate whether project objectives are being achieved • Act on results of the evaluation

8. Ensuring Good Project Objectives When an objective meets the criteria it - • Can survive the departure of a key sponsor or project management team member without diluting its clarity • Matches firm's approaches to doing business • Serves the customer need without restricting how the job is accomplished • Serves as a foundation for the work breakdown structure (WBS) S.M.A.R.T.: Specific - Measurable - Agreed to - Realistic - Timebound/Timely

9. Requirements Baseline and Exclusion Definitions Requirements Needs Requirements Baseline Exclusions Needs: Client/project sponsor requests, ideas, and business requirements Requirements: Statement of desire for a future system Requirements Baseline: Statements of commitment for future system Exclusions: Statements of "not-included" for a future system Note: Requirements baseline may also be called specifications.

10. Identify and Validate Requirements When... • Developing a proposal • Beginning a project • Taking over a project already in process (revalidating) • Reassessing the requirements of a project (mid-project)

11. Why Establish a Requirements Baseline? The requirements baseline – • Incorporates the original requirements for a project plus or minus approved changes • Serves as the basis for managing requirements • Must be signed and approved • Helps serve as the basis of ensuring that the project is complete • Defines the scope of the project

12. Requirements Baseline = Requirements -Exclusion Needs Requirements Requirements Baseline Exclusions

13. How to Establish a Requirements Baseline Needs Requirements Review N Accept able Exclusion Y Review Exception Y N Preliminary Baseline Review Y N Aproval Final Baseline

14. Specification Questions A review of fundamental questions can provide insight on a project's requirements: • What should it do? • Who are the customers? • How much will it cost the customer? • How will it be marketed? • Where will it be bought? • How will it be ordered? • How long will it last?

15. Specification Questions (continued) • Are similar products already in development or operation? • What is the expense plan? • How long is the development process? • How will it be serviced? • Can the firm's existing infrastructure support it? • What outside support is required? • How will success be defined? • What support system will firm keep in place?

16. Guidelines for Identifying and Validating Requirements • Work jointly with clients / project sponsors • Obtain detailed descriptions of problems to be solved • State the requirements explicitly and have project staff and clients / project sponsors sign off • Be realistic: assume that if a requirement can be misinterpreted – it will be misinterpreted • Use a scope definition document

17. Guidelines for Identifying and Validating Requirements continued • If possible, include pictures, graphics, models and other nonverbal exhibits in requirements formulation • Ensure that project deliverables are directly related to requirements • Establish a system to monitor changes made to the requirements • Educate the project staff and clients / project sponsors about problems in specifying requirements • Obtaine client / project sponsor signature on requirement baseline

18. Project Definition and Requirements: Organizing for Results • Project manager is the focal point • Collaborate with functional managers regarding - • Need to collect additional requirements • Who to query • Verification and validation of requirements • Sign-off process • Concept (product requirements) • Plan (product definition)

19. Using the Scope Definition Document to Identify and Validate Project Requirements • Creates a baseline for measuring and managing change • Set measures within which to control • Prevents team from jumping in and wasting effort • Ensures clarity of scope before detail planning begins

20. What is the Scope Definition Document? • Is an overview document • Sets project bounds • Establishes what the project will do and will not do • Begins to organize project into manageable form • Is not a project charter • Is not a team charter

21. Components of a Scope Definition Document • Background and summary of project • Where did this project come from? • Why is it being done? • What does the customer receive or not receive by project end? • Project objective(s) • What is the target of the project? • What problem should the project solve? • What are the major components of work on the project? • Project deliverables • What are the major products required to meet the objectives? • Customer deliverables • Project deliverables • Process deliverables

22. Components of a Scope Definition Document (continued) • Key milestones • What major points in time are important to communicate? • What major points in time are important to measure against? • What are the bureaucratic milestones? • Assumptions • What unknowns are being made into knowns? • What are the operating rules and standards? • Risks • What obstacles could jeopardize project success? • Cost • Schedule • Requirements • Quality

23. Components of a Scope Definition Document (continued) • Key resource requirements • What specialized resources are necessary to complete this project? • Human • Material • Constraints • What issues are restricting this project? • Technology • Human resources • Political • Interrelated projects • What effects are there on other programs? • What other projects are addressing related issues? • What other projects have a potential impact on this project?

24. Components of a Scope Definition Document (continued) • Acceptance criteria • What technical performance is required? • What checkpoints are in place to ensure that the right product is being delivered in the right way? • How will success be measured? • Signatures • What reviews will be done? When? • Who approves project reviews? • Reviews • At what points will management reviews be conducted? • At what points will customer reviews be conducted? • At what points will informal (team, peer) reviews be conducted? • For what purpose?

25. Components of a Scope Definition Document (continued) • Communication plan • How will team members communicate? • What types of meetings will be held? Frequency? Purpose? • What type of reports will be written? Frequency? Purpose? • Change management plan • What process will be followed when project change occurs? • Financial analysis • Net present value (NPV) • Benefit-cost ratio • Return on sales (ROS) • Return on assets (ROA)

26. Pitfalls in Defining Needs • Dealing with inherently fuzzy needs • Dynamic • Uncertainty regarding who will use the product • Identifying solutions prematurely • Addressing the needs of multiple customers • Developers' values may color and distort end-user needs • Gold-plating needs • Selective filtering of customer needs • "Father knows best" approach to recognizing and articulating needs

27. Customers aren't always sure what they need • They know what they don't need • As the product develops and takes on tangible forms, customers see new possibilities • Customers know what they want when they see it (prototype) • Customers must be taken seriously - a project may be considered a failure if the product is not utilized, is underutilized, or is misutilized by the intended customer

28. Key Messages • Always do requirements analysis and validation • Ensure that you ask the right questions • Use a systematic approach • State requirements explicitly - have project staff and the client/project sponsor sign off • Consider requirements definition between the project team and client/project sponsor • Know the differences among requirements, exclusions, and requirements baseline • Issues will occur that require management and resolution may result in change • Baselines are essential to controlling the evolution of requirements • As the project manager, assume responsibility for screening change requests, avoid scope creep, and revising the baseline