Managing Multiple Projects Without Deadlines

In an earlier post, I offhandedly referred to my policy of not agreeing to deadlines for software projects. I’ve received a bunch of questions about this. Here’s a typical one:

I am curious how you balance projects like you do without an end date. In the scenario you paint with 100% up front but client takes too long at the start of the project to get things started so the project doesn’t wrap up on time. You have signed another client or two which starts after you initially thought the first project would wrap up because you need more income. Now the first client you signed is starting to really ramp up but you have two more clients to juggle. How do you handle this scenario?

I have two answers to this question - the short one and the long one.

The Short Answer

Deadlines don’t keep projects on track - diligent communication keeps projects on track.

If you need Client A’s Project to wrap up on or around a particular date so you can get started on Client B’s Project, then it’s up to you to manage Client A. Setting an arbitrary deadline won’t help with this. If you find that you just can’t manage Client A, then you should consider firing them (or at least not working with them in the future).

The Long Answer

You probably shouldn’t be scheduling software projects back-to-back in the first place.

Scheduling projects back-to-back can be an indication that your margins are too tight, or that you’re trying to “make hay while the sun shines” (i.e., you’re in the “feast” phase of the feast/famine cycle), or that your business is not diversified enough.

In my particular case, diversification has shielded me from project scheduling issues. I virtually never schedule software projects back-to-back. I just don’t need to because I maintain a balance of money making activities. Each has a very different profile in terms of how much effort they require, when that effort is required, and whether I can pick it up or put it down without significant switching costs.

Here are some examples:

All of these offerings have pros and cons, but there are a few that are worth highlighting.

Monthly retainers have been the big winner for me. They are very stable, low risk, and much more lucrative than dev work. I can run two or three of them concurrently and they pay five figures monthly. I’ve had a number of retainer clients keep me on for a year or more.

Speaking engagements are very good money but you’re not going to be doing them every day; I shoot for roughly one per month. I’ve gotten as much as $7500 for a 1-hour speaking engagement, but my average is probably closer to $4000. Added bonus: speaking gigs are great for positioning yourself as an authority and often lead to high-value engagements like retainers or other consultative work.

Training classes and workshops have been similar in frequency and fees to speaking engagements for me, but they are more work to setup and deliver. If you’re currently just doing dev work and want to branch out without too much risk or fear, then training classes and workshops are a great place to start.

Diversification FTW!

This mix of offerings has been so strong for me that these days I rarely code for money. It’s just not worth the time, risk, or stress. Instead, I keep my dev skills sharp by working on side projects or creating educational materials. And every once in awhile I’ll make an exception and take on a client project that I find particularly interesting or meaningful (but this usually only happens once or twice per year).

If you’re booking projects back-to-back, try to think of ways you can sidestep the issue by offering a wider range of services.

One path that should work for most devs would be to start with training classes or workshops, move into speaking engagements, and ultimately to monthly retainers. Along the way you can release info products (e.g., books, videos) and pickup one-off miscellaneous work (e.g., code reviews, teardowns, prototypes, etc). 

NEXT: How To Prevent Scope Creep Without Sign-Offs