1. Defining scope

Ideally you should be able to match your project to an existing process and tool configuration that has already been applied successfully on similar projects.
Thus the scope of your tailoring will be none or relatively small.

Process tailoring is different from process instantiation. Process tailoring is about roles and procedures, whereas process instantiation is about specific individuals and specific work products. Process instantiation is covered by project management practices, and typically includes:
a. Identifying which individuals perform which roles (may include identifying backup individuals)
b. Identifying which individuals do which approvals
c. Where each work product is stored.
d. Creating project plans with work items that reflect the process.

The following are some typical examples of project-specific process tailoring:
a. Adding/removing work products and tasks
b. Changing milestones, and what work products will be made available at each milestone, and their state of completion
c. Tool and/or format used for each work product
d. Responsibilities for review and approval (a RACI table is often useful)
e. Detailed procedures for reporting progress, performing measurements, managing requirements, managing change requests, etc.

Sometimes projects will combine process tailoring and process instantiation. For example, you can create a RACI table that includes both individuals and roles, and create a table that says not only which work products will be produced, but also where the specific instances will be stored.
This blending is fine, the only drawback is that such information has to be updated for each project, and can't be used unchanged.

2. Deciding how the process will be documented

The rest of this guideline assumes you are starting with a published process documented using Rational Method Composer.
There are several options for tailoring such a process (listed here from simple to more specialized)

1. Automated
Tools can automate aspects of the process so that they do not have to be separately documented.
For example, the process template in Rational Team Concert can be tailored to require approvals before a work product is closed. Rational Requisite Pro can require specific attributes to be stored for specific requirements types. And so on.

2. Document-based
You can create one or more documents that describe how your project process varies from the published process.
The Development Case is such a document. Examples of information that may be captured in a development case are:
- differences in how roles are applied
- which artifacts are added or dropped
- what level of review formality to apply at each milestone.
Other typical process documents include:

•Manual Styleguide
•Project-specific Templates
•Measurement Plan
•Problem Resolution Plan
•Product Acceptance Plan
•Quality Assurance Plan
•Risk Management Plan
•Requirements Management Plan
•Configuration Management Plan

Word templates are provided for these documents. Note that these documents can also be implemented as a website or a Wiki.

3. Wiki-based
You can post a process on an EPF Wiki server. You can then add comments and make changes specific to your project. You can also attach documents created using the "document-based" approach.

4. RMC Configuration
You can use Rational Method Composer to change the configuration and republish it.
You can select and deselect individual practices, or use the tailoring perspective to add/remove individual elements.

5. Method Authoring
If you do need to do substantial tailoring, then you can author your own practices and plug-ins using a method authoring tool, such as EPF Composer or Rational(R) Method Composer.
Guidelines for this are outside the scope of this practice (this is considered to generally be an enterprise-scope concern).

3. Developing Project-specific Content

Ideally there is relatively little process content unique to the project.  However, project specific information needs to be captured, and your team may develop their own best practices over time.  Depending on the scope, and how you've decided to capture process content, this may be a minor step performed by one person, or may require several tasks assigned to several individuals.

4. Deciding which tools will be used to create and maintain work products
Ideally you should be able to match your project to a tool configuration that has already been applied successfully on similar projects, and just make minor tweaks specific to your project.

If you do need to make tool-fit choices, please refer to Practice: Organizational Process Definition, which has guidance on how to select, acquire, and configure tools for specific process needs.


5. Deploying the process
If only minor changes to the process have been made, then a simple briefing with affected stakeholders is generally sufficient.
However, if significant changes have been made to the process, or if the team is unfamiliar with the process being adopted, then we recommend having a workshop to familiarize the team.
Having mentors on the team, or accessible to the team, that are familiar with new practices can also increase the success of adopting the practices.
If skills are an issue, then additional training may be required and should be scheduled.