As consultant your first action was to ask the client about immediate problem. The discussion has revealed to you that there is performance measure (Y) to be improved so that to help solving existing issues. Y is the percentage of features which the deviation of target and actual delivery dates exceeded “3” days.

The derivation of Y was based on analysis, for example:

• Understand the Voice of the Customer.
• Identify the Critical to Quality variables which impacts VoC.
• Data to support the above.

Now you want to analyze further what are the input factors which affect Y, as shown next:

Let us assume we analyzed existing data based on the above factors and we found that client requests, which have contributed to the main delays in the system, are having:

Technology = Perl,

Existing module design = Based on previous architecture,

Change impact = database and services modules, and

Software configurability = NA;

In a previous post here I suggested that WIP limit tends to be not followed by people who have scarce skills, in our example here they are the Perl developers.

What this means?

This means that the empirical observation of exceeding the WIP limit for certain stage, and showing resistance by people who work at that stage, are backed by data which directly impact Y.

By having shortage in these scarce skills, Y will increase which will increase CoPQ. Therefore, we’re not economical in our delivery of maintenance requests.

Instead, I suggest adding a separate class of service for Perl based requests in the above example with its own policies.  The class of service helps to identify:

– Prioritization scheme

– Request hand-off from one stage to the other

– Expected SLA performance

– Any specific workflow rules