The estimating process for web development projects is important for us as a business to be able to sustain ourselves, as well as to build trust with our clients. Without a clear and accurate process to estimate our projects, we risk overextending our team or undercharging for our services. It’s also important for the well-being and culture of our collective team to ensure everyone’s voices are heard when internal processes are reevaluated, so we conducted an all-team workshop devoted to examining our estimating process together.
We quickly learned that our current project estimating process was creating some unnecessary stressors. Our process also demonstrated aspects of paternalism and perfectionism, which are characteristics of white supremacy culture we at Mangrove are working to identify and address.
Here’s a bit of background about why we decided to change our estimating process, and solutions for a more equitable project estimating process that we came up with as a team.
How Estimating Is Tied to Our DEIJ Work
After participating in the Hella Social Impact Intensive, a training to identify and combat white supremacy norms within our organization (you can read more about the Hella Intensive DEI training here), we identified two main white supremacy characteristics at Mangrove: paternalism and perfectionism.
- Paternalism: Decisions are made by leadership, for people not with people.
- Perfectionism: The belief that we can and have to be perfect based on standards that we didn’t create, and that achieving those standards proves how valuable we are.
To address some of these characteristics, we first held a decision-making workshop with the entire Mangrove team to democratize how we make substantial decisions so that everyone, not just the leadership team, has a voice. We learned about various daily challenges that our team members were facing, and one of the common challenges was related to how we estimate our time and effort for web development projects.
Based on this feedback, we facilitated a second workshop specifically focused on estimating. Everyone anonymously shared their stressors, processes that had worked for them in the past, and collectively came up with solutions on a digital whiteboard (we used Miro with anonymous guest contributors). This allowed each team member space to communicate by both speaking and writing (as a team with many non-native English speakers, written feedback is sometimes easier) and gave us a great resource to reference and build upon in the future.
Common Pain Points of Estimating
We asked our team to share some of their tensions around the current way we estimate web development projects. There was a lot of unspoken pressure to estimate correctly in the first place, followed by both guilt and stress when the estimates were off.
Common challenges described by our team members included:
- Having to come up with an estimate without adequate information about the task or project
- Worrying about overestimating, then erring on the side of bidding too little time
- Not logging all the hours if you get stuck on something because you underestimated a task
- Large tasks are difficult to estimate because detailed steps aren’t always outlined
- Pressure to give a quick response to clients on the spot
- Feeling like you can’t give a range because project managers and clients expect a definitive number
Democratizing Our Estimating Process
As we worked through this information together, we decided that estimates don’t always have to be perfect, and we don’t want to foster a culture where that’s expected. As a team, we also didn’t want leadership to simply aggregate all the feedback and use it to dictate a new process. It was most important that our entire team work together to create an equitable estimating process that better reflects our needs and experience. So, we discussed strategies that worked well for estimates in the past and searched for points of agreement in developing a new process that we’d all feel satisfied with.
Effective Strategies For Accurate & Democratic Web Development Project Estimates
- Invest time upfront to work on the estimate, rather than just diving in without thinking it through
- Break up the task into smaller sections, estimate each section, and then combine the time
- Add on time for the project planning phase (pseudo coding, mood-boarding, research, etc.)
- Track all hours, no matter what, so you can accurately reference past projects as a benchmark. Revisit and learn from these benchmarks.
- Always add time for content entry and review, if applicable
- Add on extra hours as a percentage of the total estimation to account for unforeseen challenges. There is ALWAYS something
- Build in ample hours for client communication
What We’re Doing Differently Going Forward
Based on our estimating workshop, we’ve made improvements to our estimating process with input from everyone on the team—designers, developers, and project managers—which not only leads to a better internal culture, but it provides an improved experience for our clients, too.
By compiling a list of features clients commonly ask for and code we’ve written in the past, we have a “menu” to give us a starting point to reference when bidding time for similar projects.
Taking the Average
Instead of putting the burden on one or two team members to come up with an estimate, we poll the group and then use the average.
Ranges Are Ok
Estimates are just that—estimates. By providing a range for more complex projects, we can give ourselves and our clients a margin of error in case of unexpected circumstances.
When a client provides us with a budget, we share it with our developers before asking them to make an estimate. That way our developers can provide alternatives to fit within the budget instead of feeling pressured to bid less time to adhere to the client’s scope.
Occasionally we go over an estimate, and when this happens, we hold a retrospective to learn why—not to place blame but to make tweaks to our process so that we can continue to improve.
We’re proud to have landed on a more equitable project estimating process that everyone feels ownership of, but we understand that it can’t be static. We plan to continue to have retrospectives, open discussions, and leave space for individuals to voice concerns and surface ideas. If you have any questions related to our estimating workshop, process, or anything else, we’d be happy to share – just reach out.