Process Tailoring
From AgileBok.org
Developing software using a well-defined, well-understood process improves the likelihood of delivering a product with the required quality. Enhancing that process to meet recognized process standards, such as CMMI and ISO 9000, can further facilitate the development of complex systems in a repeatable and predictable way. There are tradeoffs involved, however.In particular, because projects differ in their scale, scope,and technical challenge, the same process will not suit all circumstances. Agile approaches to development, such as Extreme Programming (XP), SCRUM and Crystal Methodologies, recognize this dilemma and suggest that processes be tailored to each situation. The research problem for postgraduate investigation is to determine in detail how this can be achieved successfully. This will include a consideration of how best to define, maintain and give access to a knowledge base recording details of process concepts, techniques & experience.
Overview
It is very likely that you can tailor an existing process, such as the RUP or EUP, to meet your needs. If you examine the wide array of processes in the industry, you will most likely determine that you can tailor one (or more) to meet your assessed needs. Boehm and Turner present a risk-based approach for choosing a methodological strategy, which describes how to combine agile with rigorous/prescriptive approaches. They advise that uncertain requirements, complex technologies, and low employee turnover favor agile techniques, whereas larger teams and a diverse group of stakeholders favor more prescriptive methods.
There are many processes in the industry today, and they are at varying degrees of maturity and acceptance. Pick one (or more) that will help you achieve your goals. Remember that you will still need to tailor your adopted process. Rarely will a process, even a widely accepted one like the RUP, be a perfect fit for an organization. Choose what works for you, take out what doesn't, and tweak the rest. Do you really think that you need all 3000+ pages of the RUP product? If a process makes sense to you, and you believe it will add value to your organization, then adopt it. Otherwise, do not. Do not implement processes just because someone else does. Process tailoring is best done in an iterative manner: tailor some, implement some, and then repeat. You can spend months or even years defining and tailoring the perfect process for your organization, but you won't know how it will work until you try it. You'll save time and effort (and therefore money) in the long run by taking an iterative approach.
Scope of Process Tailoring
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:
- Identifying which individuals perform which roles (may include identifying backup individuals)
- Identifying which individuals do which approvals
- Where each work product is stored.
- Creating project plans with work items that reflect the process.
The following are some typical examples of project-specific process tailoring:
- Adding/removing work products and tasks
- Changing milestones, and what work products will be made available at each milestone, and their state of completion
- Tool and/or format used for each work product
- Responsibilities for review and approval (a RACI table is often useful)
- 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.
