Activity:  Assess Current Organization

In order to configure a process and create a development case for a specific project, you need to understand the context of the project; that is the current state of the software development organization in terms of its people, its process, and its supporting tools. To successfully configure the process, it's important to understand problem areas and potential areas for improvement, as well as information about external issues such as competitors and trends in the market. When this step is complete, you need to know:

• The current state of the software-development organization
• The kinds of people involved and their levels of competence, skills, and motivation
• The tools currently used by the organization
• The current software engineering process and how it's described

The reasons for assessing the current state is so you can:

• Use the current state as input when configuring the process.
• Identify those areas that need to be improved first. You may not want to introduce the entire process and all of the tools at once. Instead, you may want to do it in increments, starting with the areas that have the greatest need and the best potential for improvement.
• Explain to the sponsors why you need to change the process, tools, and people.
• Create motivation and a common understanding among the people in the organization regarding who will be directly and indirectly affected by the changes.

Initiate an Assessment

We recommend that you initiate the assessment with a workshop where you gather the key people known at that time. The primary purposes of such an initial workshop is for the process engineers to meet the stakeholders of the project, so they can gather a comprehensive list of problems from the project's stakeholders. See Work Guidelines: Assessment Workshop for details on how to conduct this type of initial workshop.

Identify the Stakeholders

Identify the stakeholders to the process implementation effort. Identify stakeholders outside the development organization, such as:

• Customers. Who are the customers? What requirements do customers have on the products in terms of time-to-market, features, security, robustness and safety, and complexity?
• Competitors. Who are the competitors? In what areas are the competitors strong? What can you learn from competitors?
• Other stakeholders. Are there any other stakeholders involved? Are suppliers and partners involved? Are relationships with them a problem?

Identify stakeholders within the development organization, such as:

• Project members
• Project manager
• Marketing
• People in other development departments

Ask stakeholders or representatives what expectations they have on the development organization.

Describe the Internal Organization

Describe the internal organization, particularly the current roles and teams. Also, look at the relationship between different parts of the development organization. For example, what is the relationship between development and maintenance, and what is the relationship between development and test?

Identify Key People

Identify the key people in the organization by asking people in the organization. A key person is someone who has one or several of the following characteristics:

• Has the ear of the masses
• Can act as a mentor
• Is an expert in some area
• Is opposed to the process implementation
• Is responsible for the budget

• During the rest of the assessment to gather information
• As experts to help tailor the process
• To work in pilot project, then be mentor

Note: Watch out for people who want to discuss process and methodology, instead of developing systems.

Identify the Underlying Reasons for Change

Ask the stakeholders why they want to change to a new process and tools by implementing the Rational Unified Process (RUP). The following are some typical answers and their effect on how the process gets implemented:

• "We bought tools and got the RUP for 'free'. Seems like a good idea to use it."
  In this case, you probably have to be very careful when you implement the process and only implement small portions of the process to show progress.
• "We have started to use a new technology and need guidance."
  In this case, you may want to introduce only those parts of the process that guide them towards using this new technology.
• "We need a process, but we do not want to develop it ourselves. We actually tried to develop our own process, but were overwhelmed by the task. We simply couldn't afford to develop and maintain it."
  In this case, be more aggressive when implementing the process. They have developed and used process before, and are, therefore, likely to have a pragmatic view on process and its value.

Identify Competencies

Make a list of relevant competency areas, such as those shown in the following list:

• Process
  • Business modeling
  • Requirements
  • Graphic user interface design
  • Analysis & design
  • Implementation
    • Java, C++, Relational databases
• Tools
  • Rational RequisitePro, Rational Rose, etc.
• Problem domain
• Technology
  • Distributed systems, etc.
• Administrative and organizational skills
• Interpersonal and communication skills
• Organizational knowledge

For each of these competency areas, assess the knowledge, expertise, and experience of the people in the organization. There are several ways to do this:

• Ask one or several managers to rank the competencies of individuals or entire teams.
• Ask the employees themselves to rank their own competencies in each area.

For each area, estimate the individual's competency. The following is an example of a simple competency scale that can be used:

• Expert. Can act as mentor to others.
• Working knowledge. Can work independently.
• Basic knowledge. May occasionally need help.
• Novice. May not be familiar with the subject.

Make a competency profile of each individual and compile competency profiles for entire teams. It's just as important to understand the competency profile of a team as a whole because no individual alone can have all the necessary competencies.

Assess Attitudes

Interview people to understand their attitudes toward changing to new technology, new tools, and new process. If people are negative or skeptical toward the change, it's impossible to succeed with the change unless you turn their negative attitudes into positive ones.

See section "Attitudes" in Concepts: Process Discriminants for typical signs of negative attitudes and over-enthusiasm, and for methods on how to handle them.

Estimate the Capacity for Change

Analyze the capacity for change in the organization and among its individuals. When looking at the organization's problems, there's a tendency to want to fix everything all at once, especially since many of these problems occur together. This is a fatal trap. Organizations, just like individuals, can accommodate change only within a limited range. Different organizations are better prepared for change than others. To understand the organizational capacity for change, interview people in the organization to understand the attitudes and willingness to change.

Analyze the Development Process Description

Read existing process descriptions to understand the depth of the existing development process. For each discipline, identify what kinds of description they have for that discipline. For example, find out if there are no descriptions at all, and whether there are examples, guidelines, document templates, activity descriptions, artifact descriptions, and so on.

With a good understanding of the existing process, you will:

• Understand what type of process description they are used to—for example, if they already have an extensive process description, they're likely to quickly adopt the RUP, however, if they haven't had any process description before, you may have to be very careful to implement the RUP in small increments.
• Understand what areas they need most for a new process description.
• Understand what parts of their process description you can continue to use. Even if the ultimate goal is to use the entire RUP, you will implement it in increments. This means that the project continues to use some of the existing process description for a while.

Characterize the Project and Application

Describe the characteristics of projects and applications typical for the organization. Look at both finished projects and projects currently running. Collect information by interviewing individuals or entire teams. See Work Guidelines: Interviews and Work Guidelines: Brainstorming and Idea Reduction for more guidance. Study the results produced by projects—for example, project plans, artifacts produced by the project, process descriptions, project testimonials and final status assessments, and so on.

Collect the following characteristics about each project and its product:

• Size of the software development efforts. What is the size of the product?
• Degree of novelty. Where, on a scale between "green-field development" and maintenance, is the product?
• Type of application. Is the application mission-critical? Are there any requirements to follow specific standards?
• Identify what type of development the organization typically conducts. For example, is it contract work, speculative development, internal development or pre-studies. See section "Type of Development" in Guidelines: Process Discriminants for details.
• Technical complexity. What are the technical problems and challenges in building the product? For example, is the application a distributed system, a safety-critical system or a high-integrity system? Are there any legacy systems that will be reused?

To understand the factors and what effect they will have on how you tailor the process, see Guidelines: Process Discriminants.

Identify the Supporting Tools

Identify the tools that are currently being used by the projects. Identify the areas where project members lack tool support. See Concept: Supporting Tools for information.

Identify Problems

The best way to identify problems is to gather a number of key people for a problem-identification session. See Work Guidelines: Brainstorming and Idea Reduction for general advice on how to organize such a session. Notice that there are situations when it is more or less pointless to identify problems, and that is if they do not have an existing way of working (see section "Change Everything" in Concepts: Implementing a Process in a Project, for more details). 

To identify problems, ask questions such as:

• What are the problems on projects?
• Is there a perception that something is broken?
• Are projects routinely behind schedule or over budget?
• Have any metrics been collected that can be analyzed?

Make sure you cover all areas of the development process, including all disciplines, tool support, and competencies. Also make sure that you look at organizational and political issues. See section "Problems and Root Causes" in Guidelines: Process Discriminants, for a list of typical process-related problems.

Identify what negative effects each problem has, or will have, if it's not eliminated or reduced for the projects. Knowing the effect of a problem helps you understand how critical it is to eliminate or reduce that problem.

Identify the root causes of each problem to help you understand how to remove, or reduce, the problem and how much it will cost. Fishbone diagrams may help your understanding. If a problem has several root causes,  you need to weigh them against each other, in which case Pareto diagrams may be helpful.

Rank the problems with respect to the effect they cause. For example, use a 1-to-5-scale, where 5 is for problems with the most dangerous effect and 1 is for harmless problems. The primary purpose is to understand the relative importance of the problems.

List the problems in a table:

Draw Conclusions

Analyze the results of the collected information and compile a list of areas and issues on which to focus. Issues that should be addressed early usually fall into one or several of the following categories:

• Major problem areas where you can significantly improve the performance of the projects.
• Areas where you can make short-term profits and where you can quickly show results.
• Areas where an improvement will have high visibility.

Document the gathered information and the conclusions in the Artifact: Development-Organization Assessment.

Make Recommendations

Often some recommendations for the future are needed as part of the assessment. The recommendation should describe how the development project (or entire development organization) should go forward to implement the new process and tools. The recommendations could consist of outlined implementation plans, project plans, development cases, and so on.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process