Story by Alex Augustyniak
5 min read
We face them every day:
- What clothes should I wear? If it’s going to get hot, I’m sure I will regret choosing that sweater - but what if it's not hot enough - and I’m left shivering!
- How much food will be enough to prepare for my day? How hungry will I be?
- How long will it take to commute home from work? Can I pick up groceries on the way and still I'll be able to pick up the kids from school on time?
So many questions - and those are just a percentage of the number of decisions we have to face daily. As we grow older we discover our preferences for clothing and meals, prepare better for probable weather events (perhaps even check the forecast) and gain proficiency in managing our time. Fate is fickle though, and likes to remind us once in a while how irrelevant our plans can be in the face of the widely considered cosmic order. Those are some big words, but what it eventually comes down to is simple - a blown tire, a power outage, a sudden storm - as they say in the West - “Stuff happens”.
Analogous to everyday life, creating a project estimate gets increasingly harder with every unknown. The more innovative your idea is, the bigger the chance you will come upon an unexpected roadblock - possibly multiple ones.
So why is it so hard to create an accurate assessment for your project?
To answer this question let's take a look at the possible pitfalls in:
- “I’ll have what the competition has, just copy it and change some details” - the client, assuming that since the product looks simple it’s easy to create.
- “I’ll tell you how I want it once I see it” - the client, not knowing what they actually want.
- Not taking into account mobile device screen sizes/different operating systems.
- Insufficiently precise descriptions of animations, component placement, and their functionality.
- A not detailed enough description of the overall functionality, component interconnectivity, and edge cases.
- Misunderstanding of the business logic in general, boundaries of chosen technologies, and development cycle.
- Filling the project to the brim with unnecessary additions.
- Including 3rd party services which you aren’t well accustomed to.
- Project scope blowing out of proportion as requirements change during development.
Some of those are true for both worlds, infinitely more remain to be discovered in the least convenient moment.
Everyone wants the project to succeed - and considering we’re all only human - we often tend to have an idealistic view of our capabilities, and a desire to please other people by telling them what they want to hear. Just like nobody gets married while thinking of a divorce - while discussing a new project there is a lot of optimism and faith. It takes a skilled negotiator to hold those (good!) intentions back and bring the whole project down to earth.
Here are some key points for creating estimates:
Break the project down into its components.
- Example task: Create a CO2 emissions calculator with an option to donate to a charity to offset your carbon footprint.
- How not to respond: “Seems easy enough, a day for coding and design, another to implement and one more to test - will take around 3 24-hour days”
- Correct response: Let’s break this down into actual tasks:
- Find the source data for carbon emissions - 4 hours
- Design the style, coloring, fonts, and copy (text) - 12 hours
- Write code for the actual calculations - 4 hours
- Implement the calculator into a website - create a designated tab in the website, create a “smart” link, ensure it has a correct response time and that the calculations are correct - 8 hours
- Connect the calculator to an online payment system, set everything up for the client so they receive transaction data via email, and confirm that the system actually processes payments - 16+ hours, depending on the communication with the pay system provider (could be much more).
- Implement Accessibility (WCAG) - 4 hours
- Implement basic SEO rules - 4 hours
- Test everything - grammatical errors, visual bugs, payment processing, calculations, mail notifications, etc. - 8 hours
- Grand total: 60 hours (and that is a conservative estimate, without taking any unexpected accidents into account)
- Ask questions, don't assume
Propose adjusting the requirements
- Don’t be afraid to question the initial assumptions. Oftentimes during the development process, both clients and developers will change their minds about certain functionalities being necessary - or realize theirs was missing a crucial component that could greatly improve the product.
Try not to undermine what you’ve already accomplished - change course if the ratio of work required to the effect achieved is in your favor.
Take overestimation into account
- This is true for both developers and clients. Before taking on a new idea ask yourself:
- Have I done something similar before?
- Do I have all the information necessary for the project's completion?
- How familiar am I with this technology?
- Set a maximum of hours spent on a task
- Choose the correct development philosophy - Agile/Waterfall/Incremental etc.
- Communication, meetings
So how do we do it in Direktpoint?
In essence, this whole article is the answer to that question. We ask ourselves those questions with every project, and often enough we manage to discover new ones to add to the list. We don’t just accept the easiest projects with the biggest payouts - we strive to challenge ourselves by choosing important, innovative projects which we believe in.
No matter how big or small a project is, we try to put ourselves in the client’s shoes.
How would we do it if this was our company?
What is the most effective way to convince clients to buy my product?
What would I like to see if I was a customer of this company?
Years of experience under our belt allow us to ask just the right questions needed to transform your dreams into reality. What are the questions that should be asked when it comes to your project? Reach out to us to receive our opinion!