Wednesday (3/28/18) 12:08pm - ... wherein Peter thinks about how he'll do projects in 2018.
Intro: Why This Document
In 2017, I went about art wrong. I jumped from one artistic project to the next, over and over. I wound up doing a lot of work that never got finished, and a lot of work that was ultimately unsatisfying, just because I spent so much time doing, and so little time stopping and thinking about what I wanted to do.
I want to do better in 2018.
To that end, I spent January writing up a post-mortem on every project I took on in 2017. I sorted out what worked, and what didn't; what I want to do differently next time, and what I want to hold on to. Then I collated all of those results into, well, this. This will be the first of several lengthy posts -- this one's about *how* I want to tackle projects in 2018. Over the coming week, I'll put up posts about my overall goal for art in 2018, and finally what types of projects might *get* me to that goal.
Part 1: Logistics
But for now: how to do projects.
The biggest lesson out of 2017 is that I want to split out all the projects I do into three phases: Evaluation, Development, and Production.
What each phase means is pretty intuitive.Evaluation
is where I decide if a project is worth doing.Development
is where I spec out what the project is.Production
is where I actually make the thing.
I could have avoided 90% of the problems I had doing art in 2017 if I'd done my projects via these discrete phases -- making sure to do each phase, making sure to do them in order, and treating each transition as a chance to set the project aside.
First: I should actually *do* Evaluation. When I start a project, I should assess whether it's worth doing.
Yes, I'm sure a thousand inspirational memes say to leap before you look, but there's a reason the cliché goes the other way. And this could be hindsight bias, but as far as I can tell, every single project I did in 2017 that looked bad from the start wound up indeed going wrong. So yes, there's a chance, if I patiently assess projects, that I'll lose out on some unpromising looking project that actually turns out well. I just don't remember ever *doing* an unpromising looking looking project that actually turned out well -- not in 2017, not in 2016, not ever.
But then what does "assess whether it's worth doing" really *mean*, in practical terms?
"How much time will it take?"
I used to be very good at assessing scale.
I would print up checklists that listed all the Development and Production tasks, and for each task, I included a checkbox for every half-hour I expected to spend on it.
I called them "coin sheets", because originally the checkboxes were penny-sized circles, and I covered each one with a penny, one by one, until the project was finished. (Then I could gather up the pennies and re-use the printout.)
I need to do something like that again. My estimates don't need to be 100% accurate (how could they be?), but I at least need to *try*. (More on that in a bit.)
Having at least an order-of-magnitude guess at the scope is a crucial first step, because the bigger the project, the more time I should spend on Evaluation. This seems like a no-brainer -- of course, if it's a massive time commitment, think hard about whether to do it -- and again, if I'd just followed this common-sense heuristic in 2017, I would have had a much better year. I'm thinking I should take the number of hours I expect a project to take, divide that by 20, and spend that many days thinking very hard about whether I want to commit to it. So, if it's a little one-off show, have at it! If it's an acting gig in a mainstage, think about it for a week or so. And if it's a heavier time commitment, like most writing and directing tasks are, take a good two weeks to mull it over.
Another thing to consider: if it's a small project, I can do it myself; if it's a large project, I'll need collaborators; if it's a massive project, I'll need buy-in from entities like theaters or production companies. I need to assess if I'm prepared for that overhead. Which takes us to...
"Who are my collaborators?"
Vetting collaborators is pretty straightforward.
First and foremost, I want people who have done good work before. I want to click with them personally. If I'll be working with them on Development, they should have a reputation for vision: for knowing what they're making, knowing why they're making it, and sketching out the overall shape of the finished product. If I'll be working with them on Production, they should have a reputation for logistics: they should be able to handle all the grunt work -- doing, or delegating, a zillion little tasks, all on deadlines -- without flaking.
Perhaps most importantly: I should assess whether my collaborators actually want to *do* the project. Yes, I know, this should go without saying
, but I think we can all name projects where we've gotten people on board for something only to realize that... nah, they're not that into it. In that case, getting them to do work is like pulling teeth, and tasks stagnate (especially if nobody's getting paid), and you wind up choosing between doing everything yourself or leaving everything half-finished and moribund.
Not only should collaborators want to "do the project", they should be excited about doing the work that it takes to make that project happen. Sometimes people say they want to do project <x>, but they really mean that they want to *have done* project <x>, or they only want to do the cool, sexy bits of project <x>. "Let's write a novel together, but I don't want to come up with any characters, or storylines, or dialog, or prose." They need to be excited about the work itself. The tasks. The grunt work.
It's worth putting some simple hurdles in the way of collaboration. If somebody really wants to be part of something, they're probably willing to, say, schedule a meeting about it. If they're not, maybe I'm dodging a bullet by missing the opportunity.
"Does this have an audience?"
For me, this might be the most important part of Evaluation. I've done so many projects that just wound up in a drawer, or wound up gathering dust on some untouched corner of the Internet, that I've even invented my own pet name for them: "pondrocks" -- because, after all the hard work, they vanish without a trace like a rock dropped into a deep, dark pond.
Yes, I know, follow your heart, do what you care about, don't follow the crowd, be a special unique snowflake.
And yes, it's important to me to create things I love. But I think I can do both: make a thing that I care about, but make it something that at least a few people out there will value, too. It's difficult, but for me, it's the only option. At this point, I can't knowingly throw months of my life away on another pondrock.
Evaluating whether a project has an audience means ACTUALLY TALKING TO PEOPLE ABOUT THE PROJECT. Like many creative types, I worry about 'jinxing' a project if I talk too much about it too early. But for me, that's just cowardice: "What if my friends don't like it?"; "What if I tell them about something and then I can't finish it?"; questions like that. Honestly, even if the jinx is real, it's worth courting the jinx if it gives me a bead on whether at least my friends care about what I'm making.
And there's a special case here that I can't believe I have to mention, but, here we are. If I'm creating a work for some particular person or entity, make sure they actually asked me to do it. (I've been bitten twice by this one, which makes me a special kind of idiot.) If I go to the massive trouble of making a work of art only to find that the relevant gatekeeper never wanted it to begin with, then I'm probably stuck with something useless. The one producer/company/whatnot that it was targeted at doesn't want it, and it is challenging/impossible to repurpose it for anybody else.
Assessing whether it has an audience also means assessing whether it can even *be* produced. So that's a necessary question in Evaluation. If it's a screenplay, can it be filmed?
If it's a script, can it be mounted? If it's a novel, can it be published? If it's an improv-show concept, can anyone put up the show? If the project, by its nature, can't be completed, that's a strong mark against its being worth doing. And I need to remember that production includes distribution -- if there's no way to get it out to its audience, to make it accessible, and to use marketing to connect it to the people who would like it, then that audience will not be there.
"Am I excited by this material?"
Again, it seems so obvious when I write it out like that. Time and again, I've found myself taking on projects... just because they were there. With a project like that, I'd soldier through it as best as I could, but it'd be kind of a slog right from the start, because I never asked this question. If I had, I would have rightly concluded, "No, I'm not," and sensibly walked away.
Note that I've often taken on, or set for myself, projects that don't even have any material attached yet: "I resolve to write a 500-page novel about... something." It's possible to jump-start into something with just a format, and spend long hours brainstorming about what that container might contain. But generally, this is a failure state -- it'll lead to writers' block (because it's too underspecified), and frustration (because it's hard to come up with something I'm really passionate about off the top of your head), and a feeling like I'm not doing anything (because, well, I'm not).
The best case is when I've already got an idea in my backlog that would match the format well. If I hit that jackpot, I should go for it. (Note that this means I'll want a backlog of 'exciting ideas' -- more on that in a bit.)
Otherwise, I've just got a format, not a project, and I should set the whole thing aside. I should add it to some list of format ideas, and then someday later, if that format matches up with a promising idea for actual content, I'll be off and running. And if I absolutely *must* work on a format-only idea, then I should use a "drip-pan" strategy: devote five-ish minutes a day to brainstorming ideas for that, and see if anything useful crops up. If I *do* get an idea that could really work, I should run it through the whole Evaluation process that I'd use for anything else.
But in that case, I absolutely shouldn't agonize over the project. If I brainstorm for a week or two and nothing comes, then I should set it aside. There's no use beating my head against a wall, when I've surely got more auspicious things to work on.
Even if I've got material I'm excited about, it might still be a non-starter.
The *material* may not be appropriate for the *format*. If this is an improv show, do I know the *incredibly good* reason it's improvised? ("Uh... because improv is fun?" → REJECT IMMEDIATELY)
It may not be my story to tell. I'm not the right dude to tell stories about POC. I could consult with other people developing their own projects, but in all cases I need to leave it to other artists to tell stories in their own voices.
And in a broader sense, it's worth asking, "Is this material I can do justice to?", which leads to our next big question.
"How hard is this project?"
This is different from the "How much time will it take?" question about scope. Something can be time-consuming without being difficult, and taking on something difficult can lead to complete but rapid failure.
But it *is* related. If I take on a large-scale project, that's probably going to be a challenge in and of itself, just on account of all the logistics and moving parts it's likely to have. So: if it's a large-scale project, I should *that* be the sole challenge. I should not do something that's giant-scale *and* demanding in all sorts of *other* ways, too.
The biggest factor that affects difficulty is whether it's something I've done before. Directing an improv show is hard. Directing an improv show *for the first time* is much, much harder. I should definitely think twice about doing a project that's large-scale *and* new to me -- if I were, say, trying to write a two-hour musical from scratch, having never written any musical theater before (yep, tried that)... yeah, that's a bad idea. At the very least, I should find ways to scale down a project like that, so I can take it on as something manageable -- and (more importantly) completable.
Beyond that, I should have a strong sense of whether something is in my wheelhouse or not. I do better with comedy than not-comedy. I gravitate towards genre work more than literary fiction. If my gut instinct is "that doesn't seem like something I'm good at," I won't dismiss the project outright, but I'll definitely add another notch on the difficult-o-meter.
I should also consider the community resources I have available. If I'm producing a podcast, do you know anyone who can teach me audio production? If I'm trying to put up a play, are there any theater spaces available? If I'm writing a fanfic, do I know anyone in that fandom who's willing to beta-read? Again, I should ACTUALLY TALK TO PEOPLE and see what sort of support I can draw on to get the work done.
Last of all, every project has obvious, intrinsic problems. If I'm putting up Much Ado
, the main challenge is the fact that Shakespeare's written his male romantic lead to be kind of a dick. And so I would know that a good chunk of my prep time will go towards figuring out how to handle that. Even at the vague, Evaluation stage, I'll probably know what the "Claudio problems" are. I should list them out, see how nauseous they make me, and assess the challenge level accordingly.
"How fun will this be?"
Granted, a lot of this is just an offshoot of "Am I excited by this material?" Material I connect to can make up for a big pile of not-fun. But there are other considerations. Many of the challenges of a piece of art are a real slog. For instance, I co-wrote a TV spec pilot this year. It went well, but let's be real here: a spec pilot is hard. TV pilots have so many difficult structural rules that I'm basically doing the screenplay equivalent of writing a sestina
. Sometimes those challenges are fun, yes, but sometimes I'm playing "script sudoku
" as I make sure that, say, the act-outs hit at the correct page numbers.
I should always tally up the not-fun elements and take that list under consideration.
It's also worth asking how *social* a project will be. There is value in a creative project just getting me out of the house and around other people. A lot of that time might be 'faux social' -- i.e., I'm around other people but I'm really just quietly picking off errands while I'm in the same building as them -- but even that can be beneficial.
And I can probably foresee how much writers' block is going to afflict the project. If I look at the general concept and instantly start thinking of ways to sketch it out -- or, better yet, if i find myself idly exploring the material while I'm puttering around the house -- then it's probably going to be fun to work with. If no path to the finished product clearly presents itself, then I probably have an unpleasantly hard road ahead.
"Will this help the community?"
These days, I care a little less about doing good work myself, and a little more about building up a community where good work is happening. (I'll go into detail about this in the next couple of posts.)
So I should ask myself if a project is a dead end, or if it opens the door for more good art to happen around me. Teaching and directing can put new ideas into the community, and help other artists level up. Acting and writing, not so much -- those tasks are more about honing my own individual skills.
But even with teaching and directing, I can ask myself if I'll be creating a meaningful experience for the people I'm working with. If I teach people material that they won't have any use for, then I haven't made an impact. (So I should always teach students how to put the material into practice out in the world.) If I direct a show that just runs in place, artistically, it won't do much for my team or our audience. (So I shouldn't don't do that.)
For improv in particular, it's worth exploring whether the project moves the ball forward for the overall scene. With improv, there's a sort of natural gravity to the art for that wants to make every single show feel kind of the same -- light, surreal, scattered, emotionless. A good project will make it easier for everybody to get away from that "standard improv show"
, and hit some other tone, or structure, or style. Improv can do anything, but if we don't make a conscious effort at variation, it'll just do one thing, over and over, forever.
I should also remember just how white and male and cis and het improv has been since, well, forever. If I'm doing a show that's passively enforcing that, then that show is part of that problem. If I'm giving other communities a chance to improvise their stories, that's a good thing for the scene.
Odds are, in 2018, I'll get some opportunities to hop in and help with other people's projects. In that case, I should assess them by the same criteria listed above, perhaps with special emphasis on vetting whoever's running the project -- specifically, assessing what they're like to work for. Do they offer room for collaboration, or am I just receiving marching orders? (Either can be great, but I don't want any surprises.) If something goes wrong on the project, do they have my back, or am I on my own? Do they have a vision for what they want this to do for the audience? for the artistic community? (If they only think in terms of what they want the project to do for *them*, stay away.)
This is another place where the phases come in handy: are they doing Development (figuring out what the project is) or Production (actually making the thing)? If they're doing Production, er... have they actually completed Development? That is, do they know what they are making, and why they are making it? (If they don't, then stay away.) If they're doing Development, have they actually completed Evaluation? Do they have a strong sense of why this thing is worth doing? (If they don't, then stay away.) Am *I* signing on for Development, Production, or both? (If they don't know... yup, I should stay away.)
I should *write down* my initial evaluation. And every week or two, I should check back on it. Were my initial conclusions correct? Does my estimated scope match reality, or are the initial tasks taking much longer than I thought they would? Is this as easy as I thought it would be? Is it as fun as I thought it would be? If the project is turning out to be worse than I expected, I should weigh whether I want to bail.
A related point: if I'm considering taking on a project that won't *let* me bail, that's partly a good thing -- more likely to get finish it if I'm lashed to the mast -- but I should think even *harder* about whether I want to commit to it.
Whew. That's a lot of criteria. So many, in fact, that they can already give me 'priors'
about whether various projects are worth doing -- or where the pitfalls might be. For acting in an improv mainstage, I'll want to take a hard look at whether that acting gig will matter much to the community -- odds are, I can forgo trying out, and a dozen other great stage improvisors will fight to get that spot. For forming a troupe, I'll want to think hard about the time commitments, which may last forever. Directing projects don't last forever, but do eat my life for months on end -- but they can be very strong artistic statements. And so on.
But even after all that, the most important point is still the first one: Evaluation is a discrete phase, and I should do it. I should think projects over.
(Oh, and: default to "no".)
Okay, finally we can move on to the second phase: Development.
Again, Development is the phase where I figure out what, exactly, the thing *is*. Put another way, by the end of Development, if I get hit by a bus, somebody else can come in and finish it to my ghost's satisfaction.
If it's an improv show, then by the end of Development, I should nail down the basics of the show: the logline, the reaction it's going for from the audience, the *very good* reason it's improvised and not scripted, the tone of the acting, the look and feel of the tech, the basic format, and the skills that the actors and techs would need to work on.
I also know who I'm writing it for -- if I'm going to pitch it to the established theaters, or try to get a space to put it up myself.
If it's a screenplay, I know (again) the logline, the reason it exists, and the tone; I've also got some character sketches and a few scenes I might like to see. I know the format, and some of the plot -- if it's a feature spec, say, then I have tentative summaries of what happens in act two and act three.
I also know what I'm doing with that screenplay when I'm done with it -- who I'm sending it out to, or how I'll produce it myself.
If it's an improv workshop, I know what the class is about, how much time it takes, what skills it means to impart, and I have some vague ideas about exercises to include.
I also know who's interested in letting me put on the workshop, or how I'm going to put it up myself.
You get the idea. Some patterns to notice:
- In every case, there is a clear endpoint for Development. For each of these, the phase is done when I've completed <x>, <y>, and <z>. It's not a fuzzy, "eh, I'll know when I get to it" thing.
- It includes nailing down distribution. Evaluation forced us to prove that a distribution model exists; Development forces us to go further, nailing down what that distribution model *is*.
- By the end of Development, I've got enough of the girders in place that I know the project can be completed. I can't guarantee it'll be good, and I can't guarantee it'll be easy, but I'm confident I won't run into some massive unconsidered problem that renders the whole thing moot.
- Again, if I got hit by a bus, somebody else could come in and complete the project.
Thinking of it another way: if I've done my due diligence with Evaluation, then Development is really the fun part. It's a promising project, with material I'm excited about, and I get to just play. I get to do lots of blue-sky brainstorming and gradually sieve out the ideas I like best. This is the point where everything is possible and nothing is a slog.
Note that, if Development *does* become a slog, it's totally okay to bail. One thing I want to reiterate throughout this post is this: quitting is good. Hell, quitting is *great*. Quitting is dropping a useless sunk cost and freeing myself up to start something new and auspicious. Quitting is acknowledging that, y'know, I really have completed enough works of art in my life, and I have nothing to prove even to myself anymore. If I end up with twenty abandoned, half-Developed projects, and two fully-Developed projects that I loved the whole way through, that's a fabulous year.
And I'll make a related point: I've art-ed long enough that, by now, I can distinguish between different *kinds* of slogs. There's the slog of "I have to lock myself in a room, hash out these five narrative problems, and that's going to suck, but I'll get through it." There's the slog of "This is fun, but there's just a massive, daunting amount of work left on this." There's the slog of "I don't really have a vision for this project and everything is fumbling agony." And there's the slog of "There is no reason to complete this project, and every moment of effort takes willpower." If I'm having a bad time, I can diagnose if the slog means I'm in a phase of hard work, or the slog means that I should walk away.
Also, this is a perfect time for me to check back on my projections from the Evaluation phase. If my brainstorming has taken three times longer than I expected, and my work is still going nowhere? The project is probably not destined for success. (Yep, been there.)
I suspect that in some rare edge cases, I can compromise on a slog-project. If I'm close to the finish line, but I'm having a terrible time, I *can* just nail down answers -- not necessarily *good* answers -- for each of the blanks I need to fill out to finish Development, and then shelve the project. Basically, this just puts off 'bailing' to the end of Development, with me sort of half-assing my way to that phase's finish line.
One additional note for improv: I don't include rehearsals as a part of Development. My unpopular opinion: I don't think rehearsal is the right time, or the right mechanism, for figuring out what my improv show is. Coming up with the show should consist of me, in a room, thinking really hard about the show's purpose, format, and tone. It involves having lots of conversations with people I respect, hashing out ideas. But really, it's just me, using my imagination.
If I have some lapse of imagination, and I absolutely have to see actors in front of me, I can workshop some ideas -- but that is *entirely* different from rehearsal. Rehearsing is where I give my team the skills they need to do the show, and letting them practice its structural elements. Workshopping is where I get just enough people in a room to run through a thing I have in mind for the show, and running through it just enough times for me to get a feel for how it works on its feet. With workshopping, my whole purpose is to make observations, like a scientist running an experiment. And once I gather the data I need, I go back to sitting in a room and thinking hard about the show.
Under no circumstances should my whole team have to kill multiple weeks of rehearsal because I couldn't be bothered to think through some aspect of my idea.
So Development should start with that list of things I want to figure out -- the blanks that have to be filled before I can declare Development 'done'. And I can organize my work around that list. I can set up a coin sheet that includes each of those items as tasks, along with the time I expect to spend on each one. My usual work method is to spend an hour a day on a project, for a lot of days in a row, relentlessly, instead of "binging" for long work sessions. It means anything I do, I do slowly, but it lets me work on the thing, then let it rattle around in my head for twenty-three hours, then work on the thing again. That's usually good for my creativity. So I'll keep that up for 2018, ideally with several projects in Development concurrently.
Note: once I make it through Development, it is okay to quit. I am not pre-committed to doing Production as well.
And it's okay to put a project through Development and then give it away. Does somebody else want to do an improv show I came up with? Let them at it! If I have so few projects in my portfolio that I'm fiercely possessive of each of them, then, well, I'm not coming up with enough ideas. And if I absolutely can't abide giving away a Development-complete project, then I should be putting it through Production myself. (Note that "donation" is also the best possible fate for any idea that I just half-assed across the Development finish line because it was turning into a slog.)
Again, I care more about making good projects happen than I do about making them myself.
Also, I need to be okay with just hopping in, helping folks get their idea through Development, and hopping out again. This may be the only useful work I can do for helping communities that aren't "old cis het white dudes" tell their stories -- to come in, offer technical help if they want it, then leave them to produce the thing themselves.
I should *never* go straight from Development through to Production. I should always finish Development, put the project down, and then let it sit and age for a few weeks. If I come back to it with fresh eyes, and it still looks like something worth pursuing, great! I can queue it up for the next phase. But this is definitely the time for me to re-assess it and make sure it merits the hard work it's going to take to finish it.
The great thing is, the end of Development is the best possible point to make a go/no-go decision. If Development's gone badly -- I don't quite know what this project is, or why it exists, or how I'll put it together -- I can be *sure* that Production will be a slog, and the results will be subpar. But if my work in Development was solid -- if I have a clear idea what the logline is, why the project exists, what its tone is going to be -- then Production will be easy and fun. People will be more eager to work on that project that's clearly laid out. And best of all, the project itself has a great chance of turning out well.
And that takes us to Production. Finishing the thing.
Production should almost never happen.
I should be my own harshest gatekeeper, reserving Production for that rare project that has sailed through Evaluation and turned into an *irresistible* possibility in Development. It should be so good that it is easily worth spending months of my life on what's potentially a nonstop slog. (More on that in a moment.)
I should treat the three phases as a funnel.
In a year, I could see myself putting three hundred ideas through Evaluation. Then maybe only thirty of them get through Development. Then maybe only three of them make it through Production. That would be an amazing year -- not only would I finish three things I was genuinely passionate about, but I'd be sitting pretty with a portfolio of twenty-seven fleshed-out ideas, ready to offer up if the right collaborator or production opportunity came along, or ready to complete if I found the one tweak that it needed to be worth pursuing.
To be clear: production is not *necessarily* a slog. Rehearsals can be delightful. The quiet, patient business of revising a novella, over and over, can be soothing and pleasant. Nailing down my lesson plans can be satisfying.
But odds are? It's a slog. It's where I'm solving all the nasty logistical problems -- the scheduling conflicts, the plot contradictions, the endless "COME SEE MY IMPROV SHOW"-style shilling on every medium I can log into. It's where the whole project tilts over from "I'm inventing fabulous new and exciting things!" to "I'm finding solutions to the problems that Development!me blithely set for myself."
There really are only two guaranteed joys to Production: I'm finally seeing this exciting notion become a real thing, and I'm getting that real thing out to an audience.
All of this is just a long-winded way of making the point I made before: very few things should reach Production. The ones that do should be the ones that are the most delightful and the most likely to find fans. Re-assess those two qualities, going into Production -- because if I don't have those, Production will lose its only joys, and I'll be totally trapped in the Slog Mines.
N.B.: Production is also where I'm most likely to bring in collaborators, and those collaborators will count on me to actually finish the project. If it's something I'm speccing on my own, I can feel free to bail if Production goes bad. But generally, once I've started Production, I should commit to finishing it. So, again, I should think *really* hard about starting Production.
Once I'm into Production, I should steal as much from the business world as possible.
Yes, I'm making some kind of work of art, but if I'm saying, "No, every other person who's made it their life's work to finish complex projects on time has nothing to offer," then I'm being pretentious and dumb. I should break the project into small tasks. I should use an online task manager. I should make Gantt charts to manage dependencies. I should make RASCI matrixes to manage personnel. I got to wear my "I am le artiste!" beret during Development. I need to put on my Manager hat for Production.
Let me be clear: a lot of creative work happens in Production. I mean, duh. And of course the project will vary from exactly what I dreamed up in Development. I'll make discoveries in rehearsal. I'll make discoveries in revision. I'll make discoveries while teaching the class. I'll make discoveries in every detail I pound out in that finished product.
But odds are, the overall *vision* of the piece won't change. If I've built the 'funnel' correctly, the project that's in Production is one of the best-thought-out ideas I've had all year. If I do stumble on some significantly better variation on that idea in Production, welp, more power to future!me, but that outcome is staggeringly unlikely.
Hell, I haven't ever seen that happen.
And even if the project *does* change significantly in Production, it's still very, *very* worth my while to have the bones of it sorted out in Development. If I'm doing the project on my own, kinda knowing what I'm making right from the start means I can build it with a lot more confidence, and a lot less dithering, and a lot less dread (and a lot less slog).
If I'm working with collaborators, if I haven't thought through my Development, Production is going to turn into a gaggle of indecisive co-workers trying to pick a place for dinner. ("I dunno, where do *you* want to go?") If nothing else, I should spare myself *that* agony.
Also, at this point, deadlines are great -- even self-imposed deadlines with no real consequences. Those make me actually get things done. They also knock me out of being a perfectionist -- we don't need the ideal <x>, we just need the best <x> I can cough up in the next three days.
And another bit about collaborators: for many types of projects, this is where I'll bring a lot more people on board. Improv shows need casts. Fanfics need beta readers. Workshops need teaching assistance. And the same vetting procedure I described in Evaluation should apply here. Boiling it down to an executive-summary bullet list: are they excited to do the work?; have they done good work in this position before?; are they reliable?
And that's it! That's my whole brain dump about Evaluation, Development, and Production. It's a lot of words, but it's really just a cloud of details whirling around a few basic principles. If I got to send just a paragraph on the subject to start-of-2017 me, it'd go like this:s
Finishing art is overrated. Scribble down a million art projects. Pick a smattering of those, and figure out the basics of how you'd put them together. Pick the best of those, and only do those. Spend most of your year developing good ideas, and less time actually making the things. Because coming up with ideas is great -- but finishing things is only great when you're finishing things that you love.
So that's *how* I intend to do art projects in 2018. In the next post, we'll look at my overall goals for the year, and then in the post after that, I'll look at what projects I can do to get there.
_____ Yes, it's pretentious as hell of me to capitalize them like that. I just want to make it very clear that when I write (say) "Evaluation" (with the capital), I'm talking about the phase and not the overall concept.
 One thing that tripped me up: for many, many projects, I have to allocate time for research. There were a lot of projects where I forgot to think about that ahead of time, and a lot where I just forgot to do research entirely.
 This is the first of *many* points that should 'go without saying'.
 Actually, most snowflakes are identical rectangular chips. #themoreyouknow
 ... probably not, unless it's an audiodrama.
 Or, perhaps, embrace it in a way that's more specific, finding some originality in the format that a zillion other people have done flawlessly before.
 A Baysian-statistics term: these are the odds you think something is true even before you know any further information. If I have absolutely no information beyond "I'm on earth", I think there's a 50% chance it's sunny outside. That's my 'prior estimate' or 'prior'. If I know it's daytime, then my 'prior' that it's sunny might rise to 80%. If I further know we're in Seattle, then my 'prior' would plummet to around 0%.
contemplative · Music: