Purpose
-
To make the process engineers meet the stakeholders of the project.
-
To gather a comprehensive list of problems from project stakeholders.
-
To prioritize the collected problems based on stakeholders attending the workshop.
|
Guidelines:
|
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.
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.
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 Guideline: 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 tasks. If possible, set dates for interviews and future workshops.
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 described 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
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.
|