How I Make Scheduling Decisions When Two Projects Collide

A while back, I was simultaneously maintaining a language learning app and an AI writing tool. Both products were growing, but the team consisted of just me and one part-time developer. Every Wednesday morning we faced the same dilemma: both sides had urgent requests. Which one should we tackle first?

I tried various project management tools—Kanban boards, Gantt charts, time blocks. But tools can only record; they can't decide for you. The essence of scheduling conflicts isn't a lack of time—it's a lack of clarity on what to say "no" to.

The Real Cause of Resource Conflicts

For small teams, multi-project conflicts rarely come from workload exceeding capacity. They stem from three hidden problems:

Dependencies between projects are not explicitly mapped. For example, the AI writing tool needed a new API, and that API change would affect the grammar parsing module of the language learning app.
"Urgency" is judged subjectively by different people. The client says it's urgent, the partner says it's urgent, and you feel it's urgent too—but no one puts them on the same scale.
We fail to distinguish between "must do now" and "better do now". Many urgent requests are actually "better do now"—delaying them by a week won't kill the product.

A Simple Scheduling Decision Framework

I eventually devised a three-point evaluation method. Whenever a conflict arose, I'd score the requirements from both projects on three dimensions:

Survival Impact (1-5): If we don't do this requirement, will the project face quantifiable risks in the next month? Such as user churn, revenue drop, or critical dependency breakage. This asks not "will it be better?" but "will it get worse?"
Window Sensitivity (1-5): Does this requirement have a clear time window? For example, an Apple review rule change that must be adapted by next Thursday, or a competitor's new feature that must be matched before it launches. Once the window is missed, the value may drop to zero.
Resource Exclusivity (1-5): Does this requirement need a specific resource to be fully occupied? For instance, only the part-time developer can write this module, or I need to personally deploy the server. If the resource is replaceable, score lower.

Then sum the scores for each requirement. Prioritize the higher total. If scores are close, pick the one with lower resource exclusivity—it can be completed in fragments and interleaved with other tasks.

This framework sounds too simple? It is. But its value isn't in the numbers—it forces you to write down why one is more important. Each time you score, you realize that before, you were just following gut feeling saying "this is urgent."

A Hypothetical Failure Case

Suppose I scored two projects with this framework:

Project A (language learning): Survival 4 (without the new season activity, monthly active users would drop 10%), Window 5 (activity must go live by Monday), Resource Exclusivity 2 (frontend can be substituted). Total: 11.
Project B (AI writing): Survival 2 (just UI optimization, users can still use it), Window 1 (no time sensitivity), Resource Exclusivity 4 (must be done by the part-time dev who happens to be free). Total: 7.

Clearly, A should come first. But if I only looked at resource availability, I might have the part-time dev start B because "he's free right now." Once B consumed his time, A would be rushed at the last minute, quality would suffer, and the window would be missed.

This case is hypothetical, but I've seen similar scenarios in many small teams. The key insight: Resource availability should not determine priority. Priority should be determined by goals and risks, and then resources should be scheduled around it.

Boundaries and Adjustments in Practice

The three-point evaluation doesn't solve everything. It has three obvious weaknesses:

Scores are subjective. Different people may assign different numbers. Initially, have the same person (e.g., yourself) do all scoring to reduce variance.
It assumes requirements are independent, but in reality they may have dependencies. In that case, first draw a dependency graph, bundle dependent requirements into a single package, then score that package.
It doesn't account for long-term strategic weight. If a project is exploratory (e.g., a new direction), its survival impact may be low, but its strategic value is high. In such cases, I add a "strategy multiplier" of up to 1.5.

Additionally, every quarter I do a retrospective: compare my past three months' scheduling decisions against actual outcomes, and check which scores were off. For example, if I once overestimated survival impact but it didn't matter, I adjust my calibration next time.

Closing Thoughts

Resource conflicts are the norm for small teams. You're not short on time—you're short on a method to say "no." The three-point evaluation isn't a silver bullet, but it gives me a starting point that is debatable, reviewable, and correctable. If you're struggling between multiple projects, try this: at your next conflict meeting, don't open a tool first. Grab a pen and score each requirement on those three dimensions. You'll discover what you really should be working on.

PaxLee