A framework for prioritising workchunks?
When you have bitten off — or been assigned — a project that involves many tasks, how do you group and prioritise the work?
This is a question I’m finding myself grappling with more and more as I’ve recently transitioned from working at Big Tech to a 40-people startup as a senior software engineer.
From what I’ve observed in 8 years in the field, most software projects tend to have several chunks of work that seem simultaneously important and/or urgent. They’re all vying to be prioritised like little Meseeks going, “Hey look at me!”
Some Sales Director or Product Manager may occasionally flag some of your chunks to jump the queue. It’s always an urgent request.
But you are the project manager, you see, and it doesn’t matter if that’s by appointment or de facto, you’re the one responsible for delivering the goods.
So you have to decide how to prioritise the workchunks. A chaotic project board will chew away the girth of your neck like a hundred fire ants as you scramble like a bloody idiot — literally — to deliver and then fall down dead.
What’s a viable system for prioritising a software project’s workchunks?
Building widgets
Say, hypothetically, you are given the chance to lead a project that delivers an all-new widgets experience to your partners.
You’ve flown by the seat of your pants to implement an initial version that works. But you know there’s still a lot of important work to be done, like:
- Orchestrate logging and visualising of usage metrics
- Setup error tracking and reporting
- Setup alerting and monitoring of servers
- Update the documentation with a user’s guide
- Fix a bug with one of the widgets
- Eliminate unnecessary API calls to improve host site performance
You have a sprint or two to work on these… but which ones should you and your team work on first?
That’s the kind of framework I’m wishing for. One that I could systematically consider each of these workchunks against, to prioritise them in such a way that helps me help my employer receive fat stacks of cash, some of which hopefully get handed down to me and my team.
I have a hunch that a practical framework can only be distilled from mixing of a hundred interrelated factors.
But what should be factored into prioritising workchunks to deliver software projects? I can think of a bunch of questions that would be useful to ask, and they fall into two mutually exclusive buckets: the workchunk and the organisational situation bucket.
Workchunk factors
Is this really a problem?
Does this deliver value to the customer/user?
Do you have a high or low degree of uncertainty about the effort?
Organisational situation factors
Is someone’s reputation on the line if this isn’t done soon? Do you need this person’s goodwill soon?
Is this urgent? Is this tactical? Does this yield immediate revenue?
Is this important? Is this strategic? Does this yield long-term revenue?
Is there money in the bank at the moment?
Is the team well staffed at the moment?
Will this problem be solved or at least be mitigated by an adjacent chunk of work soon?
Will the implementation be undone or messed up by an adjacent chunk of work soon?
So what’s the framework?
I don’t know yet. Maybe there’s no viable framework, only a series of important questions to ask yourself before arriving at a best-guess prioritisation.
But what I find troubling about this is something I’ve observed about us: when we try to consider too many question at once with our puny brains, we tend to take the lazy route and make a snap decision that accidentally skips or wilfully ignores some of the important questions. Better make a decision than meltdown and crash.
And so the search for a framework continues.