Watch out for Waivers

Tailoring the software process is a fundamental aspect of software process management but is often poorly understood by inexperienced process teams and badly executed. This generates confusion amongst project managers and project team members and often leads to an undesirable behavioural response whereby tailoring is ignored in projects and process anarchy gains a foothold in the organisation. One key failure is to confusion between the tailoring process and the waiver process. Process tailoring (as defined by the SEI) is :

"The activity of creating a process description by elaborating, adapting, and/or completing the details of process elements or other incomplete specifications of a process. Specific business needs for a project will usually be addressed during process tailoring."

Typically a process element is an input, output, role, activity or procedure, but not restricted to these. Crucially, the act of tailoring does not change the underlying purpose of the process or process element. An example of process tailoring is to select which of the standard project management deliverables a specific project will create. Similarly, small projects may tailor the standard lifecycle to follow a less rigourous start-up process than a large project. Process tailoring decisions are made during the project launch, should be based on tailoring guidelines and are agreed with the relevant stakeholders according to specific business needs.

A Process Waiver on the other hand is a mechanism that allows the applicant (for example a project or business area) to refrain from applying or following a process. Very often process waivers are a mechanism to allow a project to perform non-conformant processes or activities.

An example where a process waiver might be used is when project is contractually required to use the client process set rather than in-house processes. Process Waivers are usually granted on a temporary basis according to an agreed business case, and are reviewed on a regular basis to ensure their currency and validity.

Neither process tailoring nor process waivers should be performed as 'get out of jail free cards' undertaken because an individual or team has elected that they don't wish to perform certain activities.

Process tailoring should be performed by all projects as part of their launch. Process Waivers should be exceptional. If projects are generating large numbers of waivers there are likely to be three possible underlying causes. Firstly the distinction between tailoring and waivers is not understood. Secondly, the tailoring process and guidelines are inappropriate, or in the third and worst case, the process set itself not properly aligned to the work being undertaken. The process group (or equivalent) should be maintaining records of all waivers and performing trend analysis against the data to establish potential process improvement opportunities. Records of tailoring decisions should also be kept for the same purpose.

One final thought is to pay attention to the granularity of process tailoring guidelines. At a minimum, process areas and process inputs and outputs should be included. Some organisations attempt to tailor at a lower level, such as tailoring of sub-sections within documents. Unless there is a very good reason for such a level of control this is probably a step too far and will generate mistrust and resistance from those people who have to create and use the documents. A good review process and culture should trap potentially critical documentation errors whilst still allowing the authors the ability to make some decisions for themselves, and will also allow a best practice culture to grow and thrive.

There's enough of a nanny state out there without needlessly bringing it into every aspect of working life as well. Print this post