Part of tailoring the RUP framework for use on a specific project is to decide on which disciplines to introduce. As described in Task: Tailor the Development Process for the Project , you should avoid using all of RUP in one single project. And if your project is fairly new to the practices described in the RUP, you should concentrate on limiting the number of unknown factors to a handful, to ease the transition of the teams onto a new process platform.

Once you have decided which disciplines you need to introduce, decide the following for each: 

• How to perform the workflow. 
• Which parts of the workflow should be used. 
• When, during the project's lifecycle, to introduce the workflows and their parts. 

To help you decide, guidelines have been developed for each discipline called "Important Decisions in <Discipline X>. In these guidelines, there are is a section called "Decide How to Perform the Workflow".  See the attached guidelines for the disciplines included in this configuration.

When you consider introducing a particular discipline, or part of one, take the following into account:

• Applicability. Is it applicable for the project? Does it really add value to introduce it?
• Problems and root causes addressed. Does it address any of the perceived problems and their root causes?
• Tool support. What tool support is needed?
• Timing. When during the project's lifecycle should it be introduced? See Concept: Implementing a Process in a Project, for more information.
• Cost of implementing. What is the cost of implementing it in the project? This includes:
  • Cost to train project members. 
  • Cost to install the supporting tools.
  • Cost to develop guidelines and templates.

Select the right set of work products for the project to produce. If you cannot clearly articulate why the work product should be produced, for example if no external stakeholder has requested it, then consider excluding it.

It is a good practice to use the development case to document any deviations from the underlying process, so exclusion of any work product should be justified and documented.

Perform the following steps:

1. Decide how the work product (modeling element or document) should be used.  For information on a classification scheme for documenting the importance of individual work products and whether or not they will be used, see Guideline: Classifying Work Products.
2. Decide the review level for each work product and capture it in the "Review Details". For details see Guideline: Review Levels. Decide how to review each work product; that is, which review procedures to use. 
3. Decide how you should capture the final results of a discipline. Do you need to store the results on paper? If so, you have to decide on one or several reports that extract the results from the tools, and capture the results on paper. 
4. Decide which tools to use to develop and maintain the work product.
5. Decide which properties to use and how to use them. See the Properties table for each work product and the section titled "Tailoring" of each work product.
6. When relevant, decide which stereotypes to use. For each work product, see the section titled "Tailoring."
7. Decide on an outline for the document work products. For the respective work product, see the "Brief Outline." portion of the main description.

In addition to these steps you should also:

• Decide which reports to use. Decide if you need any work reports to extract information from models, then document the information on paper for reviews. These work reports are usually treated as casual since they are temporary and will be discarded as soon as the review is complete. You may need to tailor the outline.

There are more things to decide for each discipline. See the "important decisions in <discipline name>" guidelines for each discipline for more details.

Study the modified set of work products and the tasks that use, create and update these work products. Decide whether you should modify or simplify these tasks. Note that for each task input and output work products are indicated. Be sure to delete any unnecessary step or task. Consider the following:

• Introduce new steps and possibly new tasks to reflects the work products, reports, and documents that you have had to add.
• Examine how the tools used can facilitate, automate, or even suppress some of the steps.
• Introduce into the tasks any specific guidelines and rules inherited from the organization's experience. They may be added as guidance points, checklists, review items, or left as separate documents that can be referenced.
• Once the tasks are known, review the workflows associated with each discipline that show how tasks interplay, removing or adding tasks as necessary.
• Whole disciplines can be omitted or created.
• You may have to introduce some additional roles to take care of special tasks requiring specific skills.

Describe the changes in the Development Case.

Choose the kind of lifecycle model the project should employ. Refine the RUP model and adjust milestones and the milestone evaluation criteria if necessary. You may even decide to omit one or several of the phases, or add or remove milestones. See Concept: Phase and Concept: Iteration for more information and ideas. Document the project's lifecycle model in section "Overview of the Development Case" of the Development Case.

In addition to selecting the overall lifecycle model, it is also important to decide how to perform the discipline workflows (what activities to perform and in what order), as well as to decide when, during that project lifecycle, to introduce each part of the disciplines' workflow.  For information on how to tailor the workflow for each of the RUP disciplines, see the usage notes for the reference workflows provided for each RUP discipline. Document the discipline workflow decisions in the Development Case.

Describe at least one sample iteration (more likely you will describe several) for each phase. These iteration descriptions describe how the project will work in different iterations and phases of the project. See the different phase descriptions under the RUP Lifecycle page for detailed examples.

The purpose of describing sample iterations in the development case is to communicate to the project teams, which tasks your project will perform, and in which order. As such it can serve as a more detailed iteration plan. The description of the sample iterations should be brief. Do not include details that belong in the tasks, work products and guidelines. You can choose to describe the sample iterations in terms of tasks or activities. Activity-based descriptions can be easier to use for planning and control at the management level, but task-based descriptions are preferred when using them at the practitioner level.

In most cases you should describe at least one sample iteration per phase. Describe the sample iterations as they are needed; there is no reason to describe how to work during the Transition phase at the beginning of a project. Start by defining how the project will work in the Inception phase.

The role Stakeholder represents all possible stakeholders to a project. You need to identify and describe the different types of stakeholders, their needs and responsibilities. Examples of different stakeholders are customer representative, user representative, investor, production manager, and buyer.

Describe the different stakeholders and their needs in the development case, in the section "Roles".

In some development organizations there are job positions defined. If these job positions are commonly used and have a wide acceptance within the organization, it may be worth doing a mapping between the roles in the RUP, and the job positions in the organization. Mapping job positions to roles can make it easier to make people in the organization understand how to employ the RUP. The mapping can also help people understand that roles are not job positions, which is a common misconception. Document this mapping in the development case, section "Roles".

Describe the development case. See the "Representation Options" section, as well as any associated guidance (e.g., templates and/or examples).

Many of the decisions should be made before the project starts. After each iteration in the software-development project you should evaluate the process, and reconsider the decisions you have made. If a new version of the underlying configuration is released, you need to update the development case.