Why is forecasting a project’s length hard?

After years of experience, forecasting a TouchDesigner project’s length is still hard. It always will be. It’s the nature of the beast. The nature of being on the generally cutting-edge of media technology and trying to use the latest-and-greatest gear and techniques. Sometimes you’ll miscalculate how long something takes (almost always you’ll underestimate!). With that said there are a bunch of steps you can take to hone in your forecasting skills, which are important for doing project specification, figuring out which jobs are worth doing (financially), and just making sure you don’t piss off your client by saying one number then having to bill them a way bigger number later. It’s also important to know that time estimates are pretty personal, since not everyone is good at the same stuff. Whereas I might bang out a complicated state machine in a few hours that I know will be rock solid, it might take me a day to make some generative art that I’d be satisfied with. Let’s dive in.

Reflection is the most important thing

Before even telling you the practical things, the most important thing you need to realize is that reflection is the key to getting better at forecasting. Unlike other skills that you might be constantly using/honing in on (technical skills), forecasting and budgeting events for most developers are few and far between. You might budget a few projects, then work on one of them for 3-6 months, then go back to square one and budget a few more projects. This is a problem because feedback loops and reflection are how we get better at things. If you do something, then forget about it for 3-6 months, you’re most certainly not going to remember everything correctly and will not be reflecting often enough to increase your skills at a noticeable pace. You’ll also tend to overcompensate. Go too low on one gig’s budget? Next gig’s budget will probably be way too high and you won’t get it. So it’s important that with everything below, you take maybe a half hour every week through the course of the project and ask yourself these key questions:

1. Are my forecasts were correct or not so far?
2. Why they might be incorrect or correct?
3. If I could immediately make a new specification for this project, how could I change the forecast to be even slightly more accurate?

If you answer these questions weekly, you’ll quickly notice how good your forecasting skills will become in a short amount of time.

Make a spreadsheet, don’t be fancy

Rule #1 of anything I do: Don’t be fancy. Rule #2: Don’t do it in your head. Excel, Google Sheets, Libreoffice Calc, Collabora, all of these are more than powerful enough for a simple spreadsheet you need to make. It’s essentially a few columns, and then a handful of rows. The first is “items” or what line item you’re forecasting time for. Second is number of units, which is usually days or hours. Third column is cost per unit, so your hourly or day rate. And forth column is just the 2nd and 3rd column multiplied together. Do that for a bunch of lines, then at the bottom, use a SUM function in the spreadsheet to add all the elements in the forth row together to get your budget and SUM all the second row for your time estimate. Take a look at a simple example I made below for a fictional project with a fictional rate at $150/hour per 8 hour day (if anyone emails me and holds me to either the days or rates listed below, I’m clicking “Report spam” in my email!):

You can see in the expression bar, the SUM feature, super easy to use, you can watch a video on it and learn it in 30 seconds. You can see in this sample, I outlined a few features as line items, and then I put an estimate on how many days it would take to build to completion. Don’t estimate how long it’ll take to almost finish, estimate how long it’ll take till you’re hands off including reviews, testing, and maybe a few tweaks. Depending on how comfortable you are with the process you can even break the list down further and further to create a more granular list that can be tracked, but at this point I would work somewhere around this level of granularity. High enough level so I can make an estimate quick to see if the client even has money, but enough details that I could track project progress and see if it matches the forecast. An important thing about these estimates is they’re always internal. I wouldn’t show a client the big breakdown. For the client I would either give them the whole number to see if the project is for real or not, or I’d group a bunch of things together, like rows 2-6 would become “software development.” No matter how much a client asks for “breakdowns” they almost never need it and are just trying to ask “why does X cost so much?” Starting with something concrete you can refer to or asking for input from team members will put you in a much better position than just riffing off the top of your head something like “I think that’ll take me a few weeks…”

Add in overhead, management, communications, reviews, etc

The reality of the working world is that development will probably be 60-70% of the actual work you have to do on a project. The other 30-40% of the job will be: client management, project specification, project management, team co-ordination (between you + integrators/contractors), phone meetings, video conferences, client reviews, internal reviews, iterations, more internal reviews, figuring out why the computer doesn’t boot, email check ups, scheduling on-site time, booking travel + accommodations, etc etc etc. The list of non-development activities always creeps upwards, and you should account for that time in your budgeting. If you’re presenting an estimate or quote with line items, some common items included in our quotes are:

• Software project management – usually because there’s more than one developer working on a project, and we always have to manage ourselves (despite what the client’s project manager might think)
• Communications and co-ordination – this includes meetings, emails, video conferences, remote controlling demos for the client, talking to other vendors that will be on the job site and making sure everything will be good
• Specification development – this is when the client wants something and has no idea how to do it. The first part  of the project is usually a lot of talking and specification and review. Make giant to-do list of features, and make sure the client signs off
• Creative development – follow up to the above, if the client/agency doesn’t have an internal design team and you need to mock up anything before actual development begins
• Installation deployment – this rate is usually different than regular development, because it means I’m usually physically tied up someone, aka I can’t work on other things, so this costs more, but it’s usually a lot less days than regular development. 1 week is normal, plus or minus maybe a few days to go run a demo with the client on-site or in a warehouse.

Add in a shenanigans fee

The ol’ shenanigans fee. Or a buffer. Or a contingency. Whatever you want to call it. This is usually just a percentage of the total you add on the final estimate just in-case things go off the rails, or the project schedule slips for reasons that aren’t yours, or any number of reasons. This is more important in flat rate billing (more on that in the next post), but it’s good to just have a general buffer in your fee for many reasons, the main two being that if you aim high and end up billing a bit less, your clients will love you, and if you aim high and client accepts, you get paid more! Win! In general this percentage fee probably depends on your comfort level with forecasting and budgeting. If you find a lot of the scope is within your regular type of work, your buffer might be small, maybe 5 or 10%. If you’re trying new things that could terribly wrong and your client will hold you to your first estimate price, then that could even be as high as 20% or 25%. Generally you wouldn’t want to reveal a line item named “Shenanigans fee,” so one approach is to hide the buffer inside of abstract line items (aka not hardware that can be price checked). So if you have a few line items for project management, or software development, or concept design, you can bump each one up a little bit to hide your buffer’s into them. You can even hide the hardware buffer prices inside of those too if the client demands you show more line items on your estimate.

Choose your billing method

In the next post, I’ll focus more on different billing methods but just so I don’t leave you hanging, once you have the time it’ll take to a do a project. You can either multiply all the time by a day rate or hourly rate and tell the client you work flat rate (bill 50% on start, and 50% on completion generally) or you present your time estimate to the client and tell them you bill hourly and send a weekly or biweekly invoice with the hours you’ve worked. More on the pros and cons of both next week!

Wrap up

Hopefully these strategies can help you improve your forecasting abilities and make sure you’re correctly estimating TouchDesigner project lengths. There’s nothing worse than thinking you’ll be done in a week and realizing you’re still at the beginning of misery after a month! Happy hunting!