- Introducing stakeholders and users
- Involving stakeholders and users in your project
- Creating a shared vision
- Bringing it all together: The Vision Document
- Do you really need to do all of this?
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Involving stakeholders and users in your project
The following steps can be applied iteratively to establish an appropriate level of stakeholder involvement in your use-case modeling activities.
Step 1: Identify Stakeholder and User Types
Because the number of actual stakeholders can be very large, you should first identify the various types of stakeholder that must be involved in the project. Model the stakeholder community by defining discrete types of stakeholders: The set of types is determined by the problem domain, user environment, development organization, and so on. Depending on the domain expertise of the development team, identifying the stakeholder types may be easy or hard. A good start is to ask decisionmakers, potential users, and other interested parties the following questions:
Who will be affected by the success or failure of the new solution?
Who are the users of the system?
Who is the economic buyer for the system?
Who is the sponsor of the development?
Who else will be affected by the outputs that the system produces?
Who will evaluate and sign off on the system when it is delivered and deployed?
Are there any other internal or external users of the system whose needs must be addressed?
Are there any regulatory bodies or standards organizations to which the system must comply?
Who will develop the system?
Who will install and maintain the new system?
Who will support and supply training for the new system?
Who will test and certify the new system?
Who will sell and market the new system?
Is there anyone else?
Okay, is there anyone else?
Stakeholder Type information
When defining the stakeholder types, be sure to capture the following information:
Name: Name the stakeholder type.
Brief Description: Briefly describe what the stakeholder type represents with respect to the system or the project. Typically, users take on the role of one or more system actors.
Stakeholder Representative: Summarize how the stakeholders will be represented within the project. This is typically done by referencing the applicable stakeholder representative role or roles.
For stakeholder types that are also user types, the following information is also worth capturing:
Characteristics: User types may be characterized in terms of their physical environment, social environment, numbers, and other general characteristics such as gender, age, and cultural background.
Competencies: Describe the skills that users need to perform their job, as well as any other relevant information about the user type that is not mentioned elsewhere. This can include their level of domain knowledge, business qualifications, level of computer experience, and other applications that they use.
A more detailed definition of the stakeholder and user types may be required if the stakeholder or user community is particularly complex. In these cases, full stakeholder and user descriptions can be produced. Examples of such descriptions are provided in the Vision documents included in the case study and template appendices.
Step 2: Identify and Recruit the Stakeholder Representatives
After the stakeholders in the project have been identified, it is time to start recruiting the stakeholder representatives who will actively participate in the project. Of particular interest are those who will be directly involved in the use-case modeling activities. Before you approach any individuals to become stakeholder representatives, you should attempt to define exactly what their roles and responsibilities toward the project will be as well as which part of the stakeholder community they will represent. You do this by defining a set of stakeholder roles and relating these to the stakeholder types that they explicitly represent.
Stakeholder Role information
When defining stakeholder roles, be sure to capture the following information:
Name: Name the stakeholder role.
Brief Description: Briefly describe the stakeholder role and what it represents with respect to the development project. Typically, the role is to represent one or more stakeholder or user types, some aspect of the development organization, or certain types of customer or some other affected area of the business.
Responsibilities: Summarize the role's key responsibilities with regard to the project and the system being developed. Capture the value the role will be adding to the project team. For example, responsibilities could include ensuring that the system will be maintainable, ensuring that there will be a market demand for the product's features, monitoring the project's progress, approving funding, and so forth.
Involvement: Briefly describe how they will be involved. For example, a permanent user ambassador will undertake use-case modeling and other requirements activities, attend requirements workshops during the inception phase, and serve as a member of the change control board.
Again, sometimes a more detailed definition of the stakeholder role is required if the stakeholder community is particularly complex or stakeholder involvement is particularly difficult to achieve. In such cases, a full stakeholder role description can be produced. Examples of such descriptions are provided in the Vision documents included in the case study and template appendices.
The set of stakeholder roles and their relative importance will evolve over time. Certain stakeholder roles may be more important during the production of the first release of the product than the later releases. For example, the initial version of a product may be aimed at only certain user types that have the characteristics of the early adopter, whereas later versions may be geared toward less technologically advanced types of users.7
When setting up the initial set of stakeholder representatives, look for users, partners, customers, domain experts, and industry analysts who can represent your stakeholders. Determine which individuals you would work with to collect information, taking into consideration their knowledge, communication skills, availability, and "importance." These individuals will make good stakeholder representatives for the project—the set of stakeholder representatives form, in effect, an "extended project team." In general, the best approach is to have a small (2–5) group of people that can stay for the duration of the project. Also, the more people there are in your extended team, the more time it will take to manage them and make sure that you use their time effectively. Often these people will not work full-time on the project—they typically participate in one or more use-case modeling and requirements-gathering workshops in the early phases of the project, and later on they participate in review sessions.
Many companies have problems establishing effective communication between the business and IT communities. Very often it is difficult for software development projects to get any time from the appropriate business people; there is usually something more important to do than worry about a system that doesn't even exist yet. Recruiting the right stakeholder representatives to participate in the project is therefore extremely important. Potential stakeholder representatives should understand the commitment required of them to provide not only the initial requirements for the solution but also ongoing guidance and review of progress. Larger projects will require full-time user and business representatives. If you cannot find stakeholders willing to make such commitments, then you probably should question the commitment of the organization to the project. In companies where this happens, there are usually patterns of two sequential projects: one to develop the wrong system, followed by another to develop the right system.
Depending on the proximity and commitment of the stakeholder community to the project, identifying the stakeholder representatives may be easy or hard. Often, this simply involves formalizing the commitment the user and business representatives are making to the project.
The following questions can help you define the stakeholder roles:
Is every stakeholder type represented?
Is every affected business unit and department represented?
Who will evaluate and sign off on the requirements specification?
Who will attend the use-case modeling and other requirements workshops?
Who will supply the domain knowledge required to develop a successful solution?
Who will be involved in any market research undertaken to justify and validate the product?
Which stakeholder types are the most important?
Who is the target audience for the release of the product under development?
The stakeholder representatives that represent the users are only one subset of the stakeholder representatives. It is important to recognize that the set of stakeholder representatives must be broader than those drawn directly from the user community. A good way to ensure that all the stakeholders are covered by the set of stakeholder representatives is to check that every stakeholder type is represented by at least one stakeholder role and that there is at least one stakeholder representative fulfilling each stakeholder role.
Step 3: Involve the Stakeholder Representatives in the Project
Various techniques can be used to involve the stakeholder representatives in the project. They include (but are not limited to) the following:
Interviews: Interviews are among the most useful techniques for involving stakeholders in a project. If you have a good understanding of the stakeholder's role, you can keep the interview focused on the issues at hand.
Questionnaires: Questionnaires are a very useful technique, particularly when a large number of stakeholder representatives is involved. Questionnaires have to be designed, and the audience targeted, with great care.
Focus Groups: A focus group allows you to sample sets of stakeholder representatives to get their perspective on what the system must do. Focus groups tend to be used to gather specific feedback on specific topics.
Advisory Boards: An advisory board is a kind of standing focus group. It provides a way to gather stakeholder perspectives without the overhead of establishing a focus group. The disadvantage compared to a focus group is that the composition of the advisory board can't be varied according to topic.
Workshops: Workshops can be a very useful way to capture requirements, build teams, and develop their understanding of the system. They should be well planned with a defined agenda that is sent to participants beforehand along with any background reading material.
Reviews: Reviews are formal or informal meetings organized with the specific intent to review something, whether a document or a prototype.
Role Playing: This is a facilitation technique that is typically used in conjunction with workshops to elicit specific information or feedback.
The choice of technique is very closely coupled to the definitions of the stakeholder roles and the availability of actual individuals to take on the responsibilities defined by the roles. There is no point in deciding that a project will have full-time ambassador users attending weekly requirements workshops if there are no experienced users in a position to take on this level of commitment. This is why the three steps should be applied iteratively and the level of stakeholder representative involvement constantly monitored. In our experience, paying attention to the stakeholder community and continuously involving them, in the project in appropriate ways significantly increases the chances of project success.
The technique most closely associated with the creation of use-case models is the workshop. These can, of course, be used to investigate many other aspects of a project, for example, to brainstorm the characteristics of the target customer, or to develop a vision statement. Chapter 5, Getting Started with a Use-Case Modeling Workshop, explicitly addresses how workshops can be used to kick-start the use-case modeling process.
To successfully build use-case models, you must have sufficient stakeholder representation in the creation and validation of the models, and stakeholder representatives must focus on satisfying the real needs of the broader stakeholder community.