Hello! My name is Travis Southard and today I will be talking about planning a project without a budget

Sometimes this looks like having a contract for a specific set of money with a maximum amount. So it is up to the development team to spend time on the most vital parts, and plan accordingly. There’s a lot of shapes of this, but they all come to:

How much time do I want to spend on this to pay myself/my team what we deserve to get paid? SO: What then about volunteer projects? Or internal ones?

We’ll get into what I have learned in my career so far from a couple of those angles and what I have found works, and what really doesn’t.

We’ll ease in with why you should even be listening to me, defining what we’re even talking about, and a method that is one of my worst working habits that’s GOTTA GO

At the top, I want to explicitly say: These are my opinions based on my experience both at work and volunteering and that these are not the standings of my employer or volunteer organization. While, of course, we may align on some things, the following is my opinion.

Here’s a few things we are NOT COVERING today, and I will not really care to dive into much. These are well-tread paths and boy do so many of you already have strong opinions on them.

Which, by the way, this will not be a “recipe” with explicit steps, but new tools for your toolbox, of which some of these listed are too.

I’ll be covering project-team-level planning, which like my professional work, may be a team of one. Complaints about other teams is a workplace issue, not a project planning one.

Let’s talk about what we, ourselves, control.

So why should you even listen to me?

Like I said at the top, my name is Travis Southard.

During the day I am the Senior Developer & Data Analyst at Community Legal Services Philadelphia as the sole member of our Digital Innovation Lab. CLS’ mission is to fight poverty, challenge systems that perpetuate injustice, and change lives through cutting-edge advocacy and exceptional legal representation.

I build web and data tools for our case workers, help them with data analysis, and administer our case management system. Has anyone here worked with LegalServer?

I volunteer as Co-Director of Code for Philly, a member group of the Alliance of Civic Technologists. use tech, data, and design as a mode of civic engagement. We’re making Philadelphia into the city we know it can be by bringing together a community of people dedicated to using their talents to improve their home, and themselves.

For years, I was a volunteer and lead of what is now the PAX (PA Expunger project), with various teammates over that time.

Before getting into software, I was a bicycle mechanic, bike tour organizer, a courier, and many other jobs.

I want to do a quick icebreaker. We can’t spend the whole time on it though I would love to spend the day on this. So:

We are going to make a website specifically for the IndieWeb that is a gachapon/bubble machine with a finite set of little pixel art guys of various rarities. Until I reset the machine with new little guys, I want people to only be able to play once. No NFTs. Yuck.

What would you start with and why?

No right or wrong answers, raise your hand if you want to answer.

My first: Draw it out with notes of what different features I want. This helps me fill out fuzzy details and make firmer choices about the design.

$0.00 budget – What we typically think of. We have no money to spend on people or supplies and need to be scrappy. These are most often volunteer projects we are making because we just want something to exist.

No Budget – We might have funding for people and maybe supplies but not a cap of hours, so we have to direct our own time. This is my work situation where I am paid but if I ask, “Is there a limit to place on this?” I might get an answer like “Oh, don’t spend too much time, it’s just a nice to have” or “This is mission critical. Make this happen.”

Urgent – Having high priority for finishing before anything else; typically because of a hard deadline or others being blocked by this not being finished. When you can avoid letting things become urgent.

In approaching working on a project, whether new or ongoing, I need to know what it is I want to work on right now. What are the things that need my attention the most right now?

When we think of project planning, we often think of looking at the whole project at the beginning and laying out steps or maybe sprints. While that is certainly part of this, for today, let’s consider the scary question: What am I working on today?

Sometimes that is obvious, but often it’s not. I work on a bunch of projects of various size and progress. This means constantly checking in with my team to see where we are and what is urgent.

I want to approach projects by laying some basic infrastructure, working with loose doodles of where I want to end up (kind of like dry-fitting or laying out the pieces into their rough places), and then fill in details.

Those details should be the functional parts first, then styling them. That gets fuzzy in the laying out phase. But it is better to demo an ugly dropdown that does a task so much more seamlessly than how we’re doing it now, than demoing a beautiful, finely crafted element that you then have to explain what it does with your mouth. Show don’t tell counts for demos too!

Also what the tool does decides how it looks. Yes, you can style in many ways, but the style needs to help communicate what the tool does and how to use it as well as being beautiful. This may feel like it cycles back to the big shapes step, and it does. Design is iterative and we get better products that way.

Here are a bunch of questions I ask myself when planning out what to work on when. These require honesty with yourself and with your team.

What skills does our team have? This changes as the team changes and even sometimes day to day if teammates are out sick, on vacation, or attending conferences.

How much can your team work in parallel is two parts: Do these tasks have a specific order or prerequisites? AND Is my team capable of this? We want it to be. It should be. But this comes from practice and process.

Prioritizing based on urgency and deadlines is huge given we have “unlimited” time but also very limited time. How much time is left is a consideration, but also, especially at CLS, missing some deadlines are much more detrimental than others. These must constantly be weighed and re-weighed.

Is there something already built that does this? Do I need to build an index of websites and catalog the web for my caseworkers?

If it exists, why aren’t we using it? Cost? Missing features? Completely unnecessary invasive data mining that would both break our duty of confidentiality and make our world a worse place? A really annoying UI? If you have too many things in process, “It’ll be fun” may not cut it.

Also, constantly ask yourself, what does done look like and what to we need to do to get there?

What does not work? What I started calling just-in-time delivery, based on the concept in shipping and manfuacturing logistics, which we saw spectacularly fail in 2020 globally and again with the Evergiven getting stuck in the Suez canal.

The idea is, I owe my coworker this dataset on Tuesday morning so I will do it Monday. Another deliverable is due Wednesday morning so I will give myself only the underestimated time I thought it would take to complete that task while I am really under the clock. That suuuuuuuuucks!

This is completely unnecessary pressure to put on yourself where you will make poor decisions from desperation or rushing. There’s no way to ensure you’re doing your best under these conditions. Our clients, stakeholders, and we deserve us doing our best.

This is also incredibly fragile since any delay will only add more onto the next task and so on recursively until you are forced to exit dramatically. Which is often the only way to break this cycle and give yourself any sense of stability in your workday.

Working this way will only pile stress on you and will prevent you from being able to take sick days or vacation without completely ruining timelines and disappointing your coworkers which then compounds more stress on.

So again: Do not do this. It will only lead to doom!

Let’s talk about making plans so our projects are getting done sustainably and reliably. Like I said at the top, this is not a recipe or set of steps. I want to outline some considerations, questions, and checkins that you should be doing with your team consistently.

Also, no, I am not doing this perfectly. I am a team of one-ish with a lot of different projects of different sizes for different teams at a 200-person organization. This is largely some work therapy for myself, and thank you for your time. You can each bill me later.

I have implemented most of these, but it all comes with practice. Let’s help ourselves get things done.

Know how fast you actually work. How much time does it take your workers to complete and deliver work?

This will change over time based on who on your team is available at the time. Who is on vacation or out sick? Are you shorthanded? (Probably) Is there something happening in your workplace, city, country that might distract us or make our jobs harder?

Now: there are PhDs dedicated to this idea, so I won’t solve this in a slide. But I have some tips for evaluating.

Tracking time on tasks or calculating completed tasks per sprint/week/month. I worked on a team at Azavea that tracked this very well. We would track what we got done considering our days off and missing people, and then use a running average to predict how much work we could expect to get done in the next sprint considering days off and who would be available. Granted, we did still feel too slow. That we were spending too many hours per task.

Whatever time you think it will actually take you, plan for it taking 125-150% of the time. So “Oh four days” becomes 5 or 6 because of course things will come up. But tell your stakeholders/collaborators/team-waiting-on-you-to-finish 200% or 8 days in this case. Under promise, over deliver. Give yourself room!

Speaking of giving yourself room: The time you spend fixing mistakes, making changes based on feedback, or writing documentation (and you should write docs, please!). But time on docs counts towards that time.

This is often a set of time we don’t really think about if we’re not having to report hours, and even then, we might miss it.

Even if things go well and smoothly for you, leave room because it happens to all of us and having that room avoids a panic situation.

Remember: It will likely take you 125-150% of what you think it will take.

Break your tasks down to the smallest possible steps. Write them down. List out the steps you think of at first. For each item in the list write out the steps it takes to do each thing.

Also yes, write them out on your index-cards-on-a-board of choice. “I’ve got it in my head” or “I told you what to do” does not count. Do your team and yourself a favor and write these down. Yes, they will change over time, but these cards are editable.

If you find yourself writing a card with a checklist on it, there is a good chance that each of those checkbox lines should be their own cards.

When I was leading a Code for Philly project, I was lucky enough to take on a fellow who would be spending 10 paid hours a week on the project for 8 weeks. That was easily double what I was spending on the project. She deserved being able to independently pick up new tasks as she finished them. And she really did. Elizabeth kicked ass!

Before she came in I kept telling volunteers “Oh ignore that task, it’s not relevant anymore ” or “Don’t follow the docs, this is how to get set up” which was bonkers. In rep for Elizabeth starting, I rewrote our documentation and combed through our cards and broke them up, filled in holes, and labeled them by difficulty, priority, and what parts of the project would be involved. The project still follows that standard

If you are in charge of your project, doing these steps and doing them well will mean that there will be much less “Hey what does this mean?” or “What should I do next?”

This also applies to larger or in-progress projects, but I have found especially helps smaller projects that come up quickly.

For projects that you plan to use similar tools to what you have used in the past: Make yourself a template. Don’t spend time asking “Wait. How do I set up X? I remember it being easier.” Use a project that is set up the way you want this next one to be, copy it, and strip it down to the infrastructure. That’s a template. You can then fork that and get going on the work.

For any project: Every time you spin up a new teammate, have them set it up from the documentation without you. Then, every time they ask you “Wait. How do I get past this error?” figure it out with them and have them update the documentation with that info. If this is built from a template, add those changes to the template’s docs as well.

This is harder to remember to do but: When you fork that template, if you update anything, also update it in the template. That will help it stay up to speed with you.

Also, wait: Does this already exist? Why aren’t you using that? This is a valid decision, but make sure the answer to “Why aren’t you using that?” is satisfying you and your team. “Because it’ll be fun” may not be enough if we have limited time and resources.

Make yourself a calendar with your deadlines on them. This will help you estimate urgency and know when your promises are getting too dense in a particular month.

If your team is regularly meeting in a particular place, a paper calendar may work to help keep those timelines top of mind. A cartoonishly big one? Events in a digital calendar too, but it’d be good to keep those in a separate folder so you can hide them when you need to.

The big part of this is understanding there’s not actually that many days between delivering this to one team and that to another. Like I said earlier, don’t trap yourself like that. Being able to see a fuzzy version of the future is a great way to (hope to) avoid that

Okay this one isn’t hard but it’s also very hard. This is about being honest with yourself. Don’t try to reassure your colleagues if you know you are in a spot where you are going to be later than expected.

Leave room for error. Remember that whole slide? Under promise and over deliver. It makes you look good and reduces stress. 125-150%

Tell them once you know (for sure) that you’ll need more time. Some deadlines you cannot flex though so you may need to reduce your scope, or skip some nice-to-haves to make that deadline.

Know what your MVP is. Know what you need where if you had to hand it in or make it live, that it would be usable and trustable.

For me, easily the biggest part of planning (and executing) a project is having a practice, as in, approaching your project from a consistent set of steps you do in every project, every feature, or every task to keep your work consistent. Those steps will change slightly each new cycle as you learn which steps are less helpful and as you find a better way to execute that step.

If you can believe it, I was a theatre kid in high school and in my early 20s. I don’t remember the scene, but I remember there was a two or three person scripted scene. After we finished, the director asked me why I chose to stand when I did. I argued that I didn’t make a choice, I just felt we were all too still. Which is that I felt we were boring and wanted to add movement for movement’s sake.

She was right to point out that was a choice I made (a bad choice), and knowing why I made the choice will make me better at my craft. Knowing why I chose to put this button here or an image there. Knowing why I moved this variable to a contants file or named a function in a certain way.

Practice is a key part of what we do. Having an intentional process with intentional choices makes us better at what we do as teams; saves us (long-term) time; establishes patterns to make reading and developing our work easier.