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
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
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
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
There are several options for tailoring such a process (listed here from simple to more specialized)
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
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:
•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
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
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
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
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.