In last week's tip, Active stakeholder participation, you were introduced to Agile Modeling (AM)'s definition of a project stakeholder. Stakeholders include anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, support (help desk) staff member, developer working on other systems that integrate or interact with the one under development, or a maintenance professional potentially affected by the development and/or deployment of a software project is such a stakeholder. This week, I'll discuss what I believe are the rights and responsibilities that project stakeholders have -- rights and responsibilities that everyone must respect for your project to be a success. These rights and responsibilities are modified from Karl Wiegers' book Software Requirements (see Resources). In the book, Weigers focuses on how to successfully work with system users -- whereas here, our focus is expanded to include all project stakeholders.
The rights of project stakeholders
- To have developers learn about their business and objectives
- To expect developers to learn and speak their language
- To expect developers to identify and understand their requirements
- To receive explanations of artifacts that developers use as part of working with project stakeholders, such as models they create with them (e.g. user stories or essential UI prototypes), or artifacts that they present to them (e.g. UML deployment diagrams)
- To expect developers to treat them with respect
- To hear ideas and alternatives for requirements
- To describe characteristics that make the product easy to use
- To be presented with opportunities to adjust requirements to permit reuse, reduce development time, or to reduce development costs
- To be given good-faith estimates
- To receive a system that meets their functional and quality needs
The responsibilities of project stakeholders
- Provide resources (time, money, ...) to the project team
- Educate developers about their business
- Spend the time to provide and clarify requirements
- Be specific and precise about requirements
- Make timely decisions
- Respect a developer's assessment of cost and feasibility
- Set requirement priorities
- Review and provide timely feedback regarding relevant work artifacts of developers
- Promptly communicate changes to requirements
- Own your organization's software processes: to both follow them and actively help to fix them when needed
In my opinion, these rights and responsibilities effectively define a contract between a development team and its project stakeholders -- a contract that must be honored for your project team to be successful. Never forget that there is more to software development than just software development.
- Modeling:
Effective Modeling Techniques for Modern-Age Software Development
- When is a model agile? Pt 1
- When is a model agile? Pt 2
- Active stakeholder participation
- Agile Modeling (AM) Home Page
- The Object Primer 2nd Edition, by Ambler, S.W. New York: Cambridge University Press, (2001).
- Software Requirements, by Wiegers, Karl. Microsoft Press, 1999.
- Using and Managing Object Technology Home Page
Scott W. Ambler is a Practice Leader for Agile Development within the IBM Methods group. He develops process materials, speaks at conferences, and works with IBM clients worldwide to help improve their software processes. Scott is author of several books, listed on his Web site at www.ambysoft.com. Scott is also a recognized Ratonal Thought Leader, whose homepage may be viewed here.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
