This morning, I got in my car to go to work and the battery was dead <groan>. I had two choices. I could use my 15-passenger van to get to work (not the most stylish choice), or bite the bullet, run to Wal-Mart, and get a new battery. Fortunately, I’m in the habit of building slack time into my morning, so I had about an hour before I REALLY needed to be on my way. Slack time helps when the unexpected happens. Do unexpected things ever happen in technology management?

As I was driving to the store, I starting thinking about unplanned work. I first heard the term when I read The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford. Understanding unplanned work was a game changer for our organization. Everyone gets handed stuff from their boss with the predictable epigraph, “I know you’re busy, BUT…” Unplanned work comes up all the time. But until you name it, it doesn’t become visible, and you can’t manage it. A lack of work visibility is the crux of most (if not all) DPSM problems.

The Phoenix Project divides technology work into four categories.

Since the book was written, we’ve had some time to consider this taxonomy of work and refine it. With the publication of ITIL Transformation, we’ve become more aware of the difference between the “day-to-day” work we do and other types work. The first category can be termed “business as usual” or BAU. The second can be termed transformations.

Business as Usual

BAU includes all of the stuff we do on a day-to-day basis. It includes all work to support the products and services we currently deliver.

Change

Based upon this, change would fall into BAU because it is necessary for continued product and service delivery. Change (i.e., Change Enablement ala ITIL), is not a type of project because it is doesn’t meet the definition – it is not unique and usually doesn’t require the creation of a temporary organization.

Operational

However, change is not the only type of BAU work we do. We do lots of day-to-day things that are not changes. For example, incident management, service request management, asset management, etc. This work may result in changes (in the change enablement sense) but is not, strictly speaking, change. So what do we call this? I would call it “operational work.”

Unplanned

But what about unplanned work? An organization I worked for was struggling to get a handle on the work it was doing. We were always operating in “pants on fire” mode, reacting to the emergency of the day. A good portion of the work was unplanned. We recognized that this was a lack of work visibility. ( Making work visible is, I think, the biggest problem we have in technology, and it always has been.) So we started tracking time on a quarterly basis – NOT the unplanned work time – but the project and operational work each team did. Our deduction was that the the sum of operational and project work would allow us to calculate how much unplanned work each team was doing (minus a fudge number for non-productive time).

What we found was that each team had a predictable percentage of unplanned work. There was predictable variation (i.e., a standard deviation) in the unplanned work and also cyclical variation over the year. Even so, within six quarters, we had enough data to calculate percentages of unplanned work for each team and calculate the mean unplanned time per team per quarter. Essentially, we had proven that we could plan for unplanned work. And this meant that unplanned work was a category of BAU.

Transformations

According to ITIL, a transformation is a “programme/project/effort that the owner/sponsor(s) needs to carry out successfully, consisting of many activities, usually divided between many workstreams.” I’m not a big fan of this definition so let’s simplify and clarify:

A transformation is a project or program that improves a product, service, value stream or organization.

Projects

Let’s look at this definition a little closer. First, transformations are always projects or a collection of related projects (i.e., a program). Because transformations are projects, they have the characteristics of projects. They are unique, time-limited, and outcome-focused. They are the antithesis of BAU.

Internal vs. Business Projects

There is functionally no distinction between business and internal projects – both are projects, exhibit the characteristics of projects, and fall under the category of transformations. There is a categorical difference, though. Business projects are those that are forward-facing, that is, projects that will improve a product or service destined for an external stakeholder. Their outcomes are within the band of visibility of the customer journey. Examples would be new or improved lines of business. Internal projects are the opposite – they seek to improve a something that external stakeholders don’t see. Examples would be improvements in the value chain, reorganizations, and organizational change management efforts.

I understand why the distinction was originally made. We used these categories as a way to determine which governance path a project fell under. Business projects were governed by the business, while internal projects fell under the auspices of the CIO. However, both of these work types can be considered transformations under our definition.

How BIG Are Transformations?

There is another difference between the ITIL definition and the new one. Last year, the ITIL Transformation authoring team wanted to denote the idea that transformations are big. It’s why the ITIL definition of transformation uses the word “many” – many activities, many workstreams. But I think there is a fundamental error with this type of thinking. All projects seek to change something, whether the change is big or small.

Transformations seek to improve products, services, value streams or the organization itself. This list is the known ‘universe’ of work in an organization, which is another way of saying that transformations apply to all types of work. But there is also a hidden cost here. Once the transformation is over, many transformations inflate BAU because they increase the future operational, change, and unplanned work of the organization.

In Summary

Based upon these points, we have two high-level categories of work defined – transformations and BAU. All projects are transformations. We subdivide transformations into internal and business projects, mainly to facilitate governance and portfolio management. Transformations can result in future inflation of BAU. BAU work consists of three sub-categories; operational, change, and unplanned. Taken together, these five categories of work define the universe of what we do in DPSM.

Bibliography

Kim, G., Behr, K., Spafford, G., & Safari, an O. M. Company. (2013). The Phoenix Project / Kim, Gene. (1st edition.). IT Revolution Press. (amul.7ca7a398.1f4e.35cb.af33.0bf0fc7e74c4). https://research.ebsco.com/plink/dcd4d451-5d77-3b11-87f9-6194db00a1b6

PeopleCert (2025). PRINCE2® Project Management Version 7. (2025). PeopleCert.

PeopleCert (2026). ITIL® Transformation (Version 5). PeopleCert. https://ebook.peoplecert.org/books/9789925391745