Guidelines: Assessment Workshop

Topics

• Prepare for the Workshop
• Who Should Attend
• Before the Workshop
• Conduct the Workshop
• Facilitate Communication
• Consolidate Results

Prepare for the Workshop

Conducting an assessment workshop means gathering all stakeholders for an intensive, focused session. Typically, an assessment workshop takes half a day or a full day to conduct.

The process engineer prepares a presentation of the approach that will be taken to implement a process. Such a presentation should take 1-3 hours, depending on the audience's background. See Concepts: Implementing a Process in an Project for details on the approach. Also see Activity: Develop Development Case.

Ask a representative of the development organization to prepare a presentation on how the development organization currently works. The presentation should take no more than an hour and covers areas, such as organizational structure, number of people, people's competence and experience, business goals and objectives, and brief descriptions of typical projects. The presentation should also discuss the underlying reasons behind the organization's decision to change process and tools, such as problems, changing business context, and so on.

Note: An assessment workshop is just one of several ways to gather information about an organization. It needs to be complemented by other methods for collecting information.

Who Should Attend

A process engineer should act as a facilitator. Normally, it's good if the facilitator is not part of the development organization. It's easier, perhaps even essential, for an external person to give a fresh perspective and to ask the necessary provocative questions that elicit underlying problems. Because changing the software development process is often politically charged, it's essential that the facilitator is respected by all parties, and is viewed as fair and impartial.

The number of participants should be between 3 and 8, including the facilitator. The assessment workshop includes representatives from several different areas of the organization to give as accurate a picture of the current state as possible. Invite a good mix of people to cover as many areas as possible, such as:

• Project managers
• Software architects
• Experienced analysts
• Experienced developers
• Experienced testers
• Development department manager

Changes in the software engineering process will affect many people in the software development organization, therefore, many people will want to be involved. There are some advantages to this because participation often breeds support. The tendency to include more people in the workshop, however, should be strongly resisted. Increasing the number of people makes the workshop harder, or impossible, to manage. As an alternative, consider having each team elect a representative to the workshop or conduct several workshops, one for each team. The purpose of the workshop is to gather information, not to make decisions. As long as people feel their concerns as adequately represented, they tend to be supportive of the process.

Before the Workshop

The facilitator needs to sell the workshop to those who should attend, thereby establishing the group who will participate in the workshop. Give the attendees preparatory material to review before they arrive, especially the process engineer who should be as well prepared as possible. The preparatory material should include an agenda for the workshop that communicates the workshop's scope and goals which need to be reviewed by each participant. Doing this will identify any possible issues or hidden agendas before the workshop begins.

The facilitator or process engineer needs access to materials such as descriptions of the development organization and descriptions of the existing process.

Conduct the Workshop

The facilitator conducts the workshop, which includes:

• Giving everyone an opportunity to speak. This is essential if the workshop is to be perceived as fair and impartial.
• Keeping the session on track. There is a great tendency for these kind of workshops to turn into gripe sessions. Identify problems, but do not dwell on them. Once a problem has been identified, move on.
• Gathering input.
• Gathering the findings.
• Summarizing the session and working out conclusions.

A typical agenda for an assessment workshop would include:

• Give a presentation of the development organization by one of its senior representatives.
• Give a presentation of the assessment approach by a process engineer.
• Identify problem areas. Conduct a brainstorming session to identify all problems in the development organization. See Work Guidelines: Brainstorming and Idea Reduction for how to conduct a brainstorming session. Make sure that every part of the development organization is covered.
• Rank the problem areas. Come up with a ranking order between the problem areas. Consider using Pareto diagrams.
• Identify the root causes of the problems. Fishbone diagrams can be helpful for doing this. Be careful not to spend too much time identifying root causes because the primary focus of the assessment workshop is to uncover visible problems. Continual information collection and later analysis by the process engineer will aim at uncovering the root causes.
• Summarize the problems. The facilitator summarizes the meeting and its outcome. Give the participants a chance to express whether they agree, or if they there is anything to add or withdraw.
• Identify two or three projects where the problems can be further studied.
• Identify persons to interview for the assessment.
• Outline a schedule for the remaining assessment activities. If possible, set dates for interviews and future workshops.

Facilitate Communication

An assessment workshop is about communication between people. To make it easier to understand each other, you need a common understanding of the software-development process. If the development organization knows the Rational Unified Process (RUP), you could use the disciplines as a roadmap to cover all the different areas of the development process. However, if the organization already uses another process and the participants do not have a good knowledge of the RUP, we recommend that the process engineer uses the customer's development process as a framework during the assessment workshop and during interviews. This makes it much easier for the participants to express themselves and you don't want to spend time during the workshop trying to teach the participants the RUP.

An example of another development process model is the ISO/IEC 12207 standard, which is referred to as activities and is organized in the following sections:

• Process implementation
• System requirements analysis
• System architectural design
• Software requirements analysis
• Software architectural design
• Software detailed design
• Software coding and testing
• Software integration
• Software qualification testing
• System integration
• System qualification testing
• Software installation
• Software acceptance support

Consolidate Results

After the assessment workshop, the facilitator, along with fellow process engineers, needs to spend more time synthesizing the findings and condensing the information into a presentable format. The conclusions should be the product of the workshop participants, rather than those of the facilitator.

The organization itself must express ownership of the conclusions if any progress is to be made. Collectively, they need to agree on the problems that need to be solved, and express them in a non-judgmental way. The purpose of the assessment is to identify areas that require improvement, not to criticize or accuse individuals.

Rational Unified Process