I had an engineering manager from one of our infrastructure teams come to me yesterday following a PI Planning prep session they’d had. His team had raised a lot of concerns about unplanned work coming into their queues and they wanted to note a risk related to that trend.
This idea of unplanned work as a risk—i.e., “The stuff we are committing to for this PI is at risk for delivery because we get a lot of requests for unplanned work over the course of any PI"—is one that comes up a lot. I tend to take these sorts of things as a cry for help, and my general response is that unplanned work is not a risk.
When teams—mostly infrastructure, in my experience, but it can happen with any sort of shared capabilties/enabling-functions sort of team—raise this stuff, what they are usually asking for is something along the lines of "Can some VP talk to The Business and tell them to go through The Process” or “People need to come to us with requirements instead of just all this random stuff” or “They need to get these things to us earlier.” I’ve been on the receiving end of these sorts of request pretty regularly throughout my tech career, and yeah—it sucks. It especially sucks when it’s some executive escalation and you have to drop everything and try to figure out what this new on-fire thing is that’s just been dropped in your lap.
The problem with unplanned work is that it is—by definition—unplanned. We call it that because we didn’t know it was coming. Had we known it was coming, we would have planned for it and then it would just be work.
And we need to get over this idea that The Business needs to stop doing this, or needs to let us know earlier, or that that they need to come to us in the proper manner with all of the details ready. That’s now how any of this works.
If the system of work and communication (official or otherwise) within the organization allowed for earlier or better notification of these needs, we would get the sooner, but it doesn’t, so we don’t. “More detailed requirements” is also a dodge; we should not be expecting (nor, I think would we actually want) business owners to come to us with super-detailed requirements completely fleshed out.
And putting more process in front of the? Forget it. Making people fill out a form or submit a ticket for the thing they need just sends them down even more poorly mapped paths to get what they’re looking for.
When people come to me wanting to raise a risk on some project, my first question is “What exactly is happening and what delivery is it putting at risk?” I get that this quesiton dodges the traditional PMO approach to risk management, wherein we come up with this whole risk register of everything that could go wrong, give each line some score, type our mitigation plans into column AF or whatever, and then crank out some heatmap. In my experience, however, no one ever looks at those except when the project manager puts it up on the screen at some status check-in and forces everyone to go through it. This kind of stuff is largely make-work.
If project managers want to build and maintain all of that, that’s their business, but what I want to know is what is actually putting delivery at risk and what help do you need to have it no longer be at risk? I want to know that because that is what executives are going to ask, and we should should be prepared with those answers.
So, what about the unplanned work?
It’s not the unplanned work that is the problem here. The problem is that we don’t have a good handle on everything that is already on our plate and we don’t have the channels and relationships in place to be able to have an informed conversation about 1) what this new thing is, 2) what will happen if we don’t do it, and/or 3) what current work we might need to bump if we were to take on this new thing. There are a lot of secondary and tertriary problems that can flow from that, but that’s the main one.
Absent a process of some sort to make that assessment and get to those answers, we will always be stuck in this position of feeling buried under all of these incoming requests with no sense of how to handle them or talk about them. And the thing is, that’s something that is entirely within the team’s control.