The Stakeholder Analysis

1. The Stakeholder Analysis Who cares about this system I’m developing and how do I make sure they: Support the work, don’t cut the funding, don’t demand the funding be cut, don’t take the funding, and want to hire us again?

3. Stakeholder Analysis • Who • When • Why • How

4. Who? • Who’s paying you? • Who do they answer to? • Who are their critics and competitors? • Who wants the opportunity they’re giving you? • Who will use what you’re designing? • Who will be affected by what you design? • Who will be affected by the physical, cultural, procedural, etc. by-products of what you design?

5. Who? • Client/Program manager • Client’s funding source • Down-stream benefactors • Competitors • Users • Users’ co-workers, neighbors, technology vendors, etc. • Your company/organization • Your partners • Your team/teammates

6. When? All the time. • Myth: System development is a linear process—e.g., analyzedesignbuildtest.

7. Why? • Client/Program manager • Client’s funding source • Down-stream benefactors • Competitors • Users • Users’ co-workers, neighbors, technology vendors, etc. • Your company/organization • Your partners • Your team/teammates Fosters Systems Thinking! Allows you to adapt your design to the broader environment.

8. Why? What happens if it’s not done? • Assuming the Customer Knows What He/She Wants • Assuming the Client Doesn’t Know • “Client doesn’t know what he/she wants” • “Users don’t know what they want” • User Rebellion • Team Rebellion • The Sergeant’s Second Job • The New PM • Power Struggles and Agenda • Six Months of Doing the Wrong Thing

9. A Balancing Act Users • Your company’s: • Profit • Legal Dept. • Growth priorities • Partner organizations • Regulators • Competitors • Your team/teammates • Down-stream users • Client

10. How? • Client/Program manager • Client’s funding source • Down-stream benefactors • Competitors • Users • Users’ co-workers, neighbors, technology vendors, etc. • Your company/organization • Your partners • Your team/teammates Communi-cation, Feedback& Adaptation Risk Management

11. How?

12. How? • Semi-structured interviews to identify stakeholders and find out their general interests: • Client’s funding source • Down-stream benefactors • Competitors • Users • Users’ co-workers, neighbors, technology vendors, etc. • Your company/organization • Your partners • Your team/teammates

13. How? • Frequent check-ins to obtain feedback • “What-if” sessions with stakeholders • What if we don’t add X to the system? How will that affect you? • Best if grounded in specific scenarios (Scenario-based what-iffing) • Human factors methods for obtaining effective feedback from users • Verbal protocol analysis • Observation • Behavioral checklists, etc.

14. The stakeholder analysis is not a static thing. It’s never complete. • Stakeholders may not be able to tell you they like or don’t like your product until you’re halfway done. • Complex information is not easily verbalized. • Complex political landscape • Complex technological needs • Complex culture

15. How? • Develop a plan for detecting and responding to changes in stakeholder position and influence.

16. The stakeholder analysis is not a static thing. It’s never complete.

17. How? There is no one right way. Look around for ideas. Your Thesis Advisors Prez Chair SMEs You Guys FAA Comp. http://www.projectshrink.com/stakeholder-adventure-maps-drawing-smileys-and-walls-3560.html

18. EyePort: Stakeholder Interest Areas

19. EyePort: Stakeholder Participation Across Lifecycle Stages

20. Your Turn: Blackboard Stakeholders: How to proceed with each?