5 Tips to Finding Success When Starting a New Project

It’s always fun when you get a chance to build a greenfield project. It’s fresh and clean and you don’t have to worry about legacy code. You also get to make all the decisions because nothing has been decided yet.

That was my experience during my internship at Planet Argon. When I started, there was a wireframe of a static website and we knew we wanted to use a charting library to display results from a survey. Otherwise, the tools were really up to me.

It’s a little nerve-wracking to start from scratch. Where do you start? How do you pick a tool that won’t be overkill or simply doesn’t meet your needs? How long do you wait before you decide it’s time to change direction? How do you know that changing direction is the right decision?

I don’t have great answers to all these questions. But I did learn a few questions to ask to make the best decisions you can with the resources you have, and steps to take to set yourself up for success on a new project.

Establish norms

Spend time getting to know your team and stakeholders. Set clear expectations around communication, who’s responsible for what, and how to seek help if needed.

How will you give status updates to the team and stakeholders? Are those updates different? What resources do you have outside of your team that could help if you get stuck on a problem? Is it ok to seek outside help or does that cause issues with confidentiality?

Check in regularly once you agree upon a strategy. In these updates, you can track progress, resolve roadblocks, seek help, and determine if anything needs to change.

Set a purpose and the definition of done

Before you start to code, make sure you fully understand your project. There are so many different ways to approach a project.

• Ask clarifying questions such as but not limited to:
• What problem will this solve?
• Who are the users?
• How will users interact with the site?
• What are must-have requirements and nice to have features?
• What is the definition of done?

Create stories or tasks that must be completed before the project is considered done. Consider dependencies so you don’t start on a task that requires something else to be done first.

Determine if there is a minimum viable product (MVP) before more time or money is put into the project.

Choose tools wisely

Most companies have a standard set of tools such as a preferred version control or bug tracker. Perhaps though, you have leeway on the frameworks or languages. Or you want to use one type of document management tool and a team member another.

Evaluate your options and give it a try. There will be disagreements on what tools to use and that's ok. Agree that you’ll start with a tool and set a checkpoint that if the tool isn’t working, you’ll pick something else. It’s better to have a checkpoint than to wait only to find out you’ve passed the point of no return.

If you’re checking in regularly and evaluating any roadblocks or time wasters, you’ll find it easier to decide what’s working well and what’s not. The trick is keeping a close eye on your time (input) vs the product (output) and use what works best for the job at hand. Don’t over-engineer.

Document! Document! Document!

It’s so important to document your goals, decisions, your definition of done and add comments to your code – even if you’re the only developer working on a project!

Don’t forget to create your readme.txt file that explains how to set up the environment. This could be a huge time suck if someone joins midway through the project. Even if you don’t plan to add resources, still document more than you think you need. What if your computer crashes and you have to set up a new computer? It happens more often than you think.

Fail fast

If things aren’t going as planned or are taking longer, don’t be afraid to make a change. I don’t mean junk the whole project, but knowing when to pivot. Failing fast just means that you’re communicating back to your team when there is a condition that may lead to failure.

Keep a level head, evaluate the condition and make quick decisions if a change is needed.