Posts Tagged ‘Maintenance’

I recall how a leading multinational hi-tech company applied triaging in planning releases of a key international business application. The basic question was: Which enhancements from the backlog should be taken up for the next release? If the answer to this simple and basic question was not arrived at in a fair and logical and consensual manner, it could lead to a lot of heart-burn in different pockets of the company, not speaking of the misalignment with the company’s established priorities.

The governance mechanism established over-all principles (or it could be the CEO setting the credo for the company) in defining which attributes mattered and how much. For instance, ‘Customer Satisfaction (back then, ‘Customer Experience’ was not yet in currency) is the number one priority for us this year, followed by Internal Operational Efficiencies.’ Statements such as these act as the guideposts for actions and decisions in a variety of situations, and more specifically in this context, helped in putting together a base set of attributes and defining priority weights for these attributes consensually with in the company. Obviously these weights were subject to revision with passing time and changing priorities. Presently, we will ignore the nag who heckles us with: ‘Can I trade 2 units of Efficiencies for 1 unit of Satisfaction?’

Representative users of the application (it was a global application for the company, remember?) assembled and heard out a short presentation on the what’s and why’s of each enhancement tabled for that release. Immediately after the presentation and clarifications, they voted as to how the enhancement contributed towards each attribute on a simple scale of 1 to 5. Each attribute score was averaged over all voters and the composite score was computed for the enhancement, combining the attribute scores with respective pre-defined attribute weights. This was repeated for all enhancements planned for that release. The enhancements were now sorted high-to-low on their composite scores. Effort estimates for each enhancement were available apriori, as also the total available effort capacity for the release. Now, the enhancements were taken up in the order of their scores and assigned to the planned release up to the point of using up the available effort capacity. There were, of course, some enhancements which for a good reason ‘jumped the queue.’ This process also pointed to any augmentation or cut-back to available effort capacity needed to pack more or less in a release.

Most companies follow similar processes in planning their application releases amidst conflicting push-pulls.

(Note: The above is a fairly generic description of the triaging process without any client specific information.)

Read Full Post »