How to Own Project Expectations

Whether you are a freelancer or a full-time developer, someone is going to ask you how long a project is going to take. You will have to outline the specifics of what needs to be done and give a time you think it could be done by. That is when learning how to estimate the scope and time of a project becomes crucial to your success as a professional developer.

Unfortunately, we can’t predict the future. There is no way to identify all the issues that could pop up. That’s what makes estimating projects so difficult.

From my own experience as a full-time developer, and doing some freelance work on the side, I’ve distilled 3 ideas to help you estimate more effectively.

You will be able to avoid anxiety, unrealistic deadlines, and burnout while building confidence with management, and within yourself.

But first, we need to get one important fact out of the way.

The people you work with are stakeholders in what you are building. They care about your success, because your success will yield the results they care about.

What they don't want is for you to be a nervous mess, frantically flailing like a Magikarp, aimlessly hoping things get done.

Stakeholders want you to win!

Manage Expectations, Upfront

You want to do your best to eliminate surprises.

Surprises will happen, but you don't want them to affect your work, the project, or your relationship with the stakeholders.

To help avoid surprises, start planning discussions with as many questions as you can. Make it so the stakeholders have to question their own choices, so that both parties know what to expect.

Some example questions might be:

• What does the project need to do?
• How will the project behave?
• What dependencies will you rely on to build the project? (other teams, integrations with services?)
• How will the project be used once you finish the work?
• What infrastructure is already present, to take advantage of?
• What infrastructure needs to be built to realize their goals?
• What business requirements are there?
• Why did they choose this architecture?
• What requirements could they live without, if they had to drop them?
• What is the hosting environment?
• How flexible does the project need to be?

All of these questions not only help remove any potential surprises, but they also help you identify potential issues you may need to work through.

After you've exhausted the stakeholders' energy with detailed questions, you now have the opportunity to outline what you think they should expect. This is when you give your opinion about their timeline and goals.

Don't sell yourself short! As a professional developer, you have valuable insight into how software is developed. The stakeholders want to hear your thoughts. They want to hear your opinions about their approach. They want reassurance that what they want is within reach. You can provide that!

Open Communication

There is a subtle pattern outlined above.

Listen, ask, and give feedback.

Once the project starts, that pattern is flipped. It becomes your responsibility to present the progress of the project to the stakeholders, and have them listen, ask, and give feedback.

You want that feedback!

Establish a regular cadence of communication, with updates. Whether it's every week, every day, or every other month, make it clear from the beginning that you will share updates of your progress.

The best form of progress is something they can see, so include screen shots, leverage a staging environment for them to play with the project, or show demo videos. Anything to help them feel confident in how things are progressing.

Don't sweat the size of the progress. What matters is that there is progress.

By communicating often and with valuable updates, you have the chance to catch potential problems quickly. And the faster you see problems, the faster they can be resolved, and prevent your velocity from coming to a halt.

Now, don't go sharing every error you get. stakeholders don't need to know about cannot read property 'derp' of undefined. What they do care about are project altering issues. Once you come across something that could slow your progress, share it, and get your stakeholders' feedback.

Experience

You don't know what you don't know, and that's okay.

You won't be able to ask all the right questions upfront. You won't be able to see speed bumps until you hit them. You won't catch issues until after you've implemented something. That is part of the process.

What you should do is learn from missteps. Write things down, study the root causes, reflect on the circumstances, and draw insights from how things blew up. That is how you will grow the most as a professional developer.

As you iterate on your own progress, you will identify new ways of managing projects, and estimating their deliver.

Remember, success is a poor teacher. Try your best to plan, discuss, and communicate with your stakeholders. Whether you achieve tremendous success, or outright flop, your experience will grow, and you will know how to do better next time.

Now go get 'em champ! 💪