Activity: Assess Current Organization
Purpose
- To describe the current status of the software organization in terms of its current
process, tools, people's competencies, people's attitudes, customers, competitors,
technical trends, problems, and improvement areas.
|
Steps
|
Input Artifacts:
- The existing organization
|
Resulting Artifacts:
|
Worker: Process Engineer |
Guidelines: Process Discriminants |
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 is important to understand the 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 should
know:
- What is the current state of the software-development organization.
- What kind of people there are, their levels of competence, skills, and motivation.
- Which tools are currently used in the organization.
- What is the current software-engineering process, and how it is described.
The reasons for assessing the current state is so you can:
- Use the current state as an input when configuring the process.
- Identify which areas 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 process, tools, and people.
- Create motivation and a common understanding among the people in the organization that
will be directly or indirectly affected by the changes.
Analyze the existing organization, process and tools. Interview both managers and
people in the organization. Use the following checklists as a guideline. In the Guideline: Process Discriminants, several of the
discriminating factors are explained.
The Business Context
- In which business domain does the organization work? How does the business domain look?
- Is the business context speculative or commercial? Or is the business context
contractual development? Or are the products developed for internal use?
External factors
- Customers. What requirements do customers have on the products? For example, in terms of
time-to-market, features, security, robustness and safety, and complexity.
- Competitors. Who are the competitors? In which areas are the competitors strong? What
can be learned from competitors?
- Other stakeholders. Are suppliers and partners involved? Are relationships with
them a problem?
Internal factors
- Development process. What are the characteristics of today's software-development
process? How is the process described? Is there a perception that something is
broken? Are project routinely behind schedule or over budget? What problems do they have?
Have any metrics been collected that can be analyzed?
- Supporting tools. What supporting tools do they currently use? What problems are related
to the use of tools? In which areas do the developers lack tool support?
- Internal organization. What roles and teams do they currently have? What is the relationship
between development and maintenance? What is the relationship between development and
test? What is the scope of the process implementation effort?
- The competencies, skills and attitudes of individuals. Make an inventory of knowledge
and skills. Interview people to understand their attitudes towards the existing
organization and their attitudes towards changes.
- Key persons. Who are the key persons in the organization? It could be important to have
their support. Involve them in the process implementation effort.
- Capacity for change. Analyze the capacity for change in the organization and among
individuals. When looking at the organization's problems there is a tendency to try to fix
everything at once, especially since many of these problems occur together. This is
usually a fatal trap. Organizations, just like individuals can accommodate change but only
within a limited range. Different organizations are better prepared for change than
others. To understand the organizational capacity for change we recommend that you
interview the people in the organization, to understand the attitudes, and willingness to
change.
Product characteristics
- Size of software-development efforts. What is the size of the product?
- Degree of novelty. Where is the product on a scale between "green-field
development" and maintenance?
- Type of application. Is the application mission-critical? Are there any requirements on
following specific standards?
- Technical complexity. Is the application complex? 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?
It is best to collect information in small groups. When you begin the assessing
activity, it is very important to involve the people who are going to work in the new
organization. First, these people know how things work, and they are the best sources of
ideas for improvement. Second, they must feel that they are part of the work, because they
are going to "own" the new organization.
When you begin the assessment work, there are at least three ways to involve the people
who are going to work in the new organization:
- Make them members of the process-implementation team.
- Interview them for their ideas and opinions based on their experience.
- Ask them to review the results.
Study the results and summarize the most important aspects of the current state. The
reason for doing this is to highlight the areas on which you should focus, both in the
short term and in the long term.
- Define the areas where you can make short-term profits. Look at all areas, processes,
tools and people.
- Define major problem areas.
| |

|