A lot of project management boils down to having the discipline to do something that you know is better in the long run, even though it might be harder in the short term. In particular, it is so much easier to assume that things will go “right” than to build some defense into your plans against the inevitable things that go wrong. We’re all under pressure to get more done, faster. Hedging against risk usually looks like accepting that we’ll do less, slower.
Of course, over the long term, that’s not how it works at all. Over the long term, including practices that defend against things going wrong leads to getting more work done, and getting better work done. Cleaning up after something derails your project almost always takes more time than preventing the derailment in the first place. Work done in the half-panicked state that excess pressure produces is usually not as good as work done under less harrying conditions.
Obviously, hedging against risk does slow you down when compared to the ideal situation in which everything goes right and all the project gods smile upon you. The real situation never matches the ideal, though. The trick to effective project management is to find the right balance between hedging against the bad things that might happen while allowing yourself to take advantage when reality tracks closer to the ideal than it usually does.
There is a concept in Kanban that helps you find this balance. It is called slack. Slack is the extra breathing room in your plans that means you aren’t running under maximum tension. Slack is the space you leave to allow the unexpected to happen. Sometimes the unexpected is a risk turning to reality, and the slack is used to just keep the project on track. Sometimes the unexpected is that nothing bad happens, and this is when slack really shines, because it is used to improve processes or try new things and innovate.
It sounds wonderful, and honestly, it is. However, it is the practice I struggle the most to implement in my own work. I often cram more tasks into my plans, gobbling up all the slack. This is probably because one of my personal time management weaknesses is a tendency to say “yes” to too many things. I think this is a common tendency, and luckily Kanban has tools to help combat it. You set work in progress limits and have downstream steps in your workflow “pull” work from upstream, rather than having the upstream steps “push” out work as fast as they can.
Still, despite understanding these concepts and doing my best to implement them, I occasionally find myself in a crunch time, with all of my slack long gone. My time is stretched to the limit. This is an extremely unpleasant place to be, because each little issue takes on outsize importance, as I watch the clock tick and fret about whether I’ll make my deadline. Sometimes, I can replan my work and get some slack back in the system. Sometimes, all I can do is remind myself to stay calm and push through the deadlines.
I’m in one of the latter situations right now, so I will end this blog post here, and get back to the other tasks on my to do list. I’m working to meet my deadlines, but also to get back to a work situation with a little slack. It is a much happier place to be!
———————–
If you’re intrigued by the idea of slack and want to learn more, Julia Wester at Everyday Kanban has a nice write up on it in the context of software development, and Pawel Brodzinski has another look with more definitions, again in the context of software development. These two examples are from the world of software development because that is where a lot of the kanban process thinking is happening these days. However, I think slack is generally useful, and this is one of the agile project management concepts I think is most relevant to research environments, where there are goals and deadlines that must be met, but where we also need to allow space for discovery.
Be First to Comment