By Karen Ford

Have you ever worked on a project that didn’t have any defined requirements when you started on it? And even after requirements were initially determined, they continually changed? And after you’d build a feature, it would get removed, and you’d have to get rid of your work? As much fun as this sounds (read: not at all), it can be very challenging to be on a project like this. Morale suffers, as do any feelings of accomplishment. It can also be challenging to know where to start on these ill-defined projects. Here are some suggestions for making it through.

Where to start?

When you get on a project and there is very little defined, it can feel like there is no good starting point. How can you work on a feature when there are little to no defined requirements? 

Where do I start?

  1. Ask questions. You can start by talking to whomever defined the feature, whether it’s a designer (graphic or UX), project manager, or someone else. They can fill you in on the things that are known. Once you have that information, make sure you write it down somewhere either digitally or (*gasp*) in a notebook for reference later.
  2. Don’t worry about making it future-proof. This isn’t a scenario where you can expect to build this feature once and never go back to touch it again. That’s ok! Build knowing that there will be changes later. This one can be hard for some (*cough* me).
  3. Dive in. Sometimes the best way to start is to just do it. You’ll figure out the holes as you go. Do your best to build based on what you do know. But, you’ll run into some unknowns. Be aware, and most importantly…
  4. Document. Document. Document. Since you’ll definitely run into things you just didn’t know what to do about, make sure to document those things somewhere. Put them in a doc, email them, write them down, or all of the above! And even better, call them out as you go after completing the feature in question.
Ch-Ch-Ch-Ch-Changes

Congratulations, you built the feature (with or without all of the requirements defined). But now, inevitably, the feature is changing. You may be frustrated with this turn of events.

why?

  1. Stay Calm. Remind yourself that the requirement wasn’t fully fleshed out before, so this isn’t unexpected. It isn’t anything you did wrong, it’s just how things go sometimes.
  2. Find the good. Remember that the goal on a project isn’t just to get ‘er done, but also to learn! Focus on ways to do that. Did you do something haphazardly the first time around? Now is the chance to fix it. Did you want to do it differently, but didn’t have the time? Implement it a new way this time around. Is there a team member who hasn’t worked on the feature, but perhaps wanted to? Pass this on to them, and give them that experience.
  3. Rinse and repeat. Refer back to steps 1-4 from the first section. They are still important! The fact that you are changing it now means it might happen again.
It’s all gone.

You worked on the feature. It changed. It changed some more. And now…the feature is being removed. 

delete all the things

  1. Process your feelings. Give yourself time to be frustrated (or mad, or sad, or whatever you’re feeling!). It’s normal, and you need to allow yourself a moment to deal.
  2. Shift your perspective. Maybe you weren’t happy with how the feature had turned out, and this is an opportunity to remove work you didn’t feel satisfied with. Or maybe this will give you an opportunity to start over in a totally different way. Either way, try to think of this in a different light.
  3. Remember the goal. This one was already mentioned above, but is so important to your sanity! As stated before, the goal isn’t always to complete something, but to learn along the way. Did you learn something from working on the now-removed feature? Yes? Fantastic. Job well done! Are you now more knowledgeable/stronger in something that you weren’t before? Even better! If that feature is no longer there, you can still take comfort in knowing that you’re more solid in that thing you did the next time you encounter it in a project.
  4. Team build. Sometimes you just want to complain or talk about your frustrations. Your teammates might be feeling the same way! This can be a good opportunity to find ways to bond with your teammates. Commiserate, but try not to put all your energy and focus on the negative. It can be a slippery slope that just turns into a Who Can Complain the Most game, which can make things feel worse. Find ways to work together on things, or plan a team activity!

Hopefully these tips and reminders can help you get through that challenging project, and find ways to feel more empowered and less frustrated and discouraged. These things can be tough! And most importantly, remember to always take care of yourself. Not everyone is cut out for this type of work. Remember to prioritize your mental well-being. And if you can’t handle a process like the above, speak with someone about perhaps moving on to a different type of project. You’ve got this!

Looking for work?

If you’re looking for work on a dev team, sign up for our Career Lab. We’ve got openings for Developers, QA Engineers, Product Owners, DevOps, and UI/UX Designers. It’ll be us and our (secret) client as they look to build their team using our practical approach to interviewing. You’ll work through hands-on exercises designed to showcase your skills in a comfortable and collaborative environment.

Basically an interview without the pressure of an interview.

Career Lab

Karen is a front-end web developer at Detroit Labs who has a passion for creating beautiful, user-friendly, well-coded digital experiences, whether it be websites, applications, or any other digital medium. She’s been in the industry for 13+ years working with major brands and building award-winning websites. When not coding, she enjoys baking delicious cupcakes, playing violin, and hanging out with her adorable 3 year old daughter, husband, and dog.