Project Management Requirements

1. Project Management Requirements Minder Chen, Ph.D. CSU Channel Islands Minder.chen@csuci.edu

2. Problem Analysis Roadmap Solution idea or Opportunity Business Problem Identify stakeholders for problem. Root cause analysis. Business problem defined Actual problem identified and defined Understand the problem in the context of the business goals. Problem validated/adjusted Choose the best solution(s) to meet the goals. Reassess that the solution idea is the best solution. Elicit Requirements Best solution identified Expand stakeholder list for solution.

3. Root Causes: What Are the Problems Behind the Problem? Fishbone Diagram Techniques The perceived business problem. Want Privacy when banking No Banking at night Too much waiting Customers are dissatisfied with our service. Queues in the branches are too long Want more banking locations Banking in airports List contributing causes to the identified problem.Keep asking “Why?” (expand each rib).

4. Gain Agreement on the Problem Definition Problem Statement The problem of (describe the problem) (the stakeholders affected by the problem) affects the impact of which is (what is the impact of the problem) a successful solution would (list some key business benefits of a successful solution) Vision

5. Collect/Define Requirements

6. Scope, Time, and Cost • Scope Management: Identifying what needs to be done • Time Management: Identifying how long it will take to do everything • Cost Management: Identifying how much it costs to get things done

7. Collect Requirements • The project management team must identify both internal and external stakeholders in order to determine the project requirements and expectations of all parties involved.

8. Requirements • Many organizations categorize requirements into project requirements and product requirements. • Project requirements can include business requirements, project management requirements, delivery requirements, etc. • Product requirements can include information on technical requirements, security requirements, performance requirements etc.

9. Challenges in Requirements Elicitation

10. Challenges in Requirements Elicitation http://www.whattofix.com/blog/archives/2008/05/peace-for-pachy.php

11. http://www.businessballs.com/treeswing.htm Check this out http://www.businessballs.com/businessballs_treeswing_pictures.htm

12. What Are Sources for Requirements? Analyst Requirement Specs Business Models Business PlansPersonal Goals Partners Customer Users Problem Domain Site Visits Domain ExpertsIndustry Analysts Competitive info Initial Requests Bug ReportsChange Requests

13. What Problems Might Be Encountered? • Stakeholders • Have a pre-conceived idea of the solution. • Do not know what they really want. • Are unable to articulate what they want. • Think they know what they want, but do not recognize it when it is delivered. • Analysts • Think they understand user problems better than users. • Everybody • Everyone sees things from their own point of view. • Believes everyone is politically motivated. ? ? Stakeholder Analyst

14. Collect Requirements: ITTO Additional discussion at PMBOK p. 104-105

15. Techniques for Eliciting Stakeholder Requests • Requirements workshop • Use-case workshops • Brainstorming and idea reduction • Interviews • Questionnaires • Role playing • Prototypes • Storyboards • Review customer requirement specifications

16. Laundry List

17. Interview Techniques

18. Define Scope • Define Scope is the process of developing a detailed description of the project and product.

19. Project Scope Statement • Product scope description. Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation. • Product acceptance criteria. Defines the process and criteria for accepting completed products, services, or results. • Project deliverables. Deliverables include both the outputs that comprise the product or service of the project, as well as ancillary results, such as project management reports and documentation. The deliverables may be described at a summary level or in great detail. • Project exclusions. Generally identifies what is excluded as from the project. Explicitly stating what is out of scope for the project helps to manage stakeholders’ expectations. • Project constraints.

20. Project Management Plan Baseline • Once the project management plan is baselined, it may only be changed when a change request is generated and approved through the Perform Integrated Change Control process. • Project baselines include, but are not limited to: • Schedule baseline, • Cost performance baseline, and • Scope baseline.

21. Collect Requirements

22. Establish Requirements Baseline • Feature 1: The system must... • Feature 2: The system must... • Feature n: The system must... Requirements Baseline The set of features that constitutes the agreed upon basis for development and that can only be changed through a formal procedure. How do we know what the needs are? How do we determine priority? Where do we set the baseline? Time Project Start Date Target Release Date

23. Scope • Two aspects of scope: product scope and project scope. • Every successful project produces a unique product: a tangible item or service. Customers usually have some expectations about the features and functions of products they consider purchasing. • Product scope describes the intended quality, features, and functions of the product — often in minute detail. • Documents that outline this information are sometimes called product specifications. • A service or event usually has some expected features as well. We all have expectations about what we’ll do or see at a party, concert, or sporting event.

24. Project Scope • Project scope, on the other hand, describes the work required to deliver a product or service with the intended product scope. Project scope is usually measured in tasks and phases. • Product scope and project scope are closely related. The project manager who manages project scope well must also understand product scope or must know how to communicate with those who do.

25. Sample Scope Constraints • Your organization won a contract to develop an automotive product that has exact requirements — for example, physical dimensions measured to 0.01 mm. This is a product scope constraint that will influence project scope plans. • You are constructing a building on a lot that has a height restriction of 50 feet. • You can use only internal services to develop part of your product, and those services follow a product development methodology that is different from what you had planned.

26. Scope Management Problem Problem Features Solution Space Development Team User/Customer Problem Space Capture Needs Traceability System to build Software Requirements Design User Doc Test

27. Scope Management Tension • Scope management is maintaining a “healthy tension” between what the customer wants (maximum features) and what development believes it can deliver in a fixed timeframe. • It is essential for the developer to get agreement from the customer regarding a baseline set of features to develop for the system to be built. • A good way to achieve the balance between customer desires and developer resources is by using iterative development and providing incremental “slices of the pie.” Then, the priorities can be reassessed at the end of each iteration. • The ideal time to decide what the baseline set of features we will actually develop is after the system is defined and before we have put a lot of time into refining the details.

28. Avoiding Scope Creep, But Allowing Change • ‘Real’ requirements: Identify what is really needed (not want) to achieve business objectives. • Minimum requirements: A conscious practice of a minimum requirements strategy, no ‘gold plating’, no including what ‘might be needed. • All requirements should be recorded and identified by source. • Realize all requirements have a cost and schedule impact. • The use of an agreed negotiation and sanctioning process (it need not be heavyweight). • All requirements come (in the end) through a well-identified channel, not from various and sundry random sources. • Expectation management and communication with the customer about what will be in each iteration (via prototyping and iterative development). This helps uncover hidden requirements, unknown to the naïve developer but assumed by the domain-experienced customer.

29. Uses for Requirement Attributes Attributes link project elements Cost Priority Status Risk Effort $$$ FEAT 10 Approved Low High FEAT 13 $$ Proposed Medium Low FEAT 40 Approved High High $ = Filter

30. Process Helps Manage Scope Scope management and change management are inextricably linked. New Feature Reqt Customer andUser inputs Single Channel for Approval New Requirement Design Marketing ApprovedDecisionProcess (CCB: Change Control Board) Code Coders inputs Testers inputs Bug Test ChangeRequest (CR) Help Desk User inputs Maint

31. Manage Expectations • Why manage expectations? • So customers understand why you are deferring functionality • People perceive things differently • Things happen A new car! A new car! Gause & Weinberg, 1989

32. How to Manage Expectations • Understand customer expectations. • Limit the expectations as appropriate. • Include the source of the limitation. • Under-promise and over-deliver. Keep the possibilities open.

33. Improve Your Negotiation Skills • Start negotiations with high demands, but don’t be unreasonable. • Separate the people from the problem. • Focus on interests, not positions. • Understand your Best Alternative To a Negotiated Arrangement (BATNA) – Bottom line. • Invent options for mutual gain (win-win). • Use diplomacy. Improve your skills at every opportunity. Fisher, Ury, Getting to Yes, 1991

34. The Product Champion • Prevents projects from drifting into a technical or political abyss. • Helps manage project scope. • Owns the product vision. • Advocates for the product. • Defends against feature creep. • Negotiates with management, users, and developers. • Maintains a balance between customer needs and what can be delivered on time. • Represents the official channel between the customer and the development team.

35. Divergent and Convergent Thinking http://chriscorrigan.com/parkinglot/?p=1265

36. The Groan Zone • Generating new ideas can be • Time-consuming • Painful • So why bother??! • Better solutions with diversity of opinions • Help participants understand • Complexities • Trade-offs • Constraints

37. Design Thinking http://blogs.sap.com/cloud/2011/04/19/co-innovation-2-0-at-sap-design-thinking-and-a-user-centric-approach-to-meet-customer-needs/

38. Group Problem Solving Process • Gather ideas for stakeholder requests/needs. • Clarify and organize the ideas. • Condense ideas. • Prioritize remaining ideas.

39. Brainstorming • Generates as many ideas as possible. Rules for Brainstorming • Clearly state the objective of the session. • Generate as many ideas as possible. • Let your imagination soar. • Do not allow criticism or debate. • Combine ideas.

40. Brainstorming Advantages and Disadvantages • Advantages • Used anytime, anywhere. • Good for groups. • Good for high-level entities and assumptions. • Amenable to some automation. • Disadvantages • Susceptible to group processes. • Unsystematic in “classic” form. Takeda et al. 1993

41. Idea Reduction: Prune and Organize http://www.leanyourcompany.com/methods/Using-Affinity-Diagrams.asp

42. Idea Reduction: Prioritize Ideas • Prioritize remaining ideas. • Vote • Cumulative votes • Buy ideas • Single vote • Apply evaluation criteria • Non-weighted • Weighted Rational University “bucks”