There are two concepts in project management that are often mentioned in my circles at the moment. Rightly, or wrongly, people are increasingly trying to align their thinking to Class Of Service or Pace Layering. The latter is especially popular, with companies like Gartner encouraging it’s use in accelerating innovation.

I’m seeing Pace Layering being misunderstood and confused with Class of Service, for a number of reasons. for example:

• People want to be effective in prioritising work and use pace layering as way of putting projects in the appropriate box for consideration.
• People want to leverage tactical solutions that don’t have much “Customer Pull.”
• There is an unhealthy attitude towards technical debt, which people want some hybrid of the two approaches to address.

Understanding that a service is of a particular class, gives an understanding of how urgently we must deliver it. So usually you would have, half a dozen, classes of service to give a card on a Kanban board the required right bound momentum. We assess the risk involved with not delivering the item, and use this to guide us. We also know that for the duration of the delivery, the class is unlikely to change. This makes it great for prioritisation, especially for people looking down from a ‘High Level Board,’ towards delivery teams.

I have also found people trying to use Pace Layering for prioritisation. We could look at Systems of Record and see that we are affecting ways of doing things that change slowly. So we automatically start to think of them as lower class, job that will take ages and have a lot of connective tissue to consider. Systems that differentiate a business from it’s competitors can be seen as a slightly higher class of service. Human nature is going to provide more enthusiasm about these items, and put them before those boring old core business tasks. What the confusion about Pace Layering does for the shiny new items is the scariest. It is seen as the top layer, so gets equated to first class of service. This means that now nobody wants to work on those boring old differentiators, or less still the systems of record, they just want to be building the shiny new stuff, because the business doesn’t value the other stuff any more.

What we’re failing to notice here is Pace Layering is not for deciding what something is going to be, a decision made at the start, that we have to stick to forever. It is about understanding that when something is shiny and new, it is giving us one thing. In middle age, the application has proved it is adaptable, so we can expect it to embrace change whilst aligning well to core values. Further maturation of an application, that has survived many modifications, would see it providing core values as opposed to aligning with them.

It is this understanding of the life cycle of applications, that shows the utility of pace layering. If we decide that a product is only ever going to be an innovation piece, there is real danger of it just being a vanity project, or something which fails to deliver lasting value. If we set off to instantly produce a “Core, slow change, mature, common,” line of business application. We’re really saying that we’re going to build all that maturity into the product from the start. That sounds awfully like a “Big Bang,” deployment coming at the end of a waterfall project.

So to clarify, we would use Class of Service to help us prioritise, because it helps us understand how urgently something is needed and how that decision is made. We use pace layering to understand at a fairly high level, what rate of change is desirable, how long the “Kill Time,” ought to be and how the relative pace of programs fits into an overall strategic vision.

There is a lot more to discuss around this subject as it gives such a rich insight into the lifestyle of solutions that we deliver.