Every time I need to do estimates, I cringe a little. I no longer do estimates for small and medium clients since it creates false expectations and takes a huge amount of time.
Which is why I talk about pricing and budgets a lot:
I got involved with business development and estimations in 2007 as a Java developer, estimating custom development for several clients. Every now and then I need to break a project into small components, and then smaller tasks that I could put a number next to and send a rough offer.
I sent another proposal for a larger project today and I wasted many hours fine tuning the numbers. I added a long paragraph in my email with the attachment explaining why those estimates are inaccurate and basically vague, unrealistic and subject to change.
Since I’m a great supporter of the agile model for various reasons, here are my 7 main reasons why estimates and fixed price projects should be avoided whenever possible.
1. Your Estimate is Never Accurate
I shared the CHAOS report study in my latest WP Elevation post on 7 Common Pitfalls Leading to Scope Creep. The numbers are alerting: 15% of all web projects fail and yet 59% generate some form of loss – delays, extra features, unexpected changes and non-planned ones. Not to mention that a good number of the quotes are actually rejected if they predict the risk upfront, due to other offers that fall in one of the first two categories.
Based on the past 10 years of experience in the software development industry, I’ve seen two types of fixed-price projects:
- Projects that generate loss and are generally not profitable for the contractor/agency
- Projects with hyped numbers that cost several times the time spent on development, management, communication and testing
WordPress development (alongside with other types of web development) is usually a creative process that requires a unique approach to each project.
If you are a construction worker responsible for carrying bricks and other construction materials, it may be possible to estimate the amount of time it takes you to move 5000 pounds of bricks. It’s a repetitive activity that requires you to grab several bricks from point A, bring them to point B, get back and repeat.
Even so, there are various factors such as back pain, low blood pressure, high temperature outside that makes the transportation environment more troublesome (or rain) and so forth. But in general, it’s somewhat predictable.
Web development isn’t. There are thousands of things that could go wrong due to various unexpected exceptions. Unless you add a significant buffer for rainy days, you will certainly spend more hours than expected and generally delay the project.
2. Estimates Require Forever to Calculate
In order to build a detailed estimate, you need to break the entire project into generic components. Each of those components should be turned into smaller blocks, and then separable tasks for every small activity.
You have to build use case diagrams and flow charts for all of the possible activities. Larger projects require projection of visits and traffic, which determines the hosting environment. There is the communication time, and management and testing iterations. There are meetings and calls for syncing the process and solving problems on the fly.
UI-related projects often require iterations. And every now and then issues with various browsers or mobile devices occur.
Building larger systems requires custom development and bundling blocks together. Incompatibility issues are possible.
Multilingual projects need a 100% translatable application, and you’ll always miss several strings – so you’ll have to get back, fix the i18n compatibility, generate the updated .mo files and so forth. Oh wait, if you change a core plugin or theme, this would be overridden by the next update, so you probably need a child theme or extend the plugin and replace the views. Or otherwise add the extra time for maintainability post-update.
These are just a few generic examples. Last week we spent almost a day tracking a UI bug breaking the header of a site. Turned out to be an encoding issue, a file was changed using UTF-8 with BOM and broke the entire output of WordPress. The fix is “invisible”:
That’s something that none of us could predict, and it was hard to identify. But it happens regularly, with most projects.
3. Estimates Don’t Define Quality
Estimates are a measure of “how long would it take to build X?”. Building a project or a components doesn’t say anything about quality.
And customers often compare apples with cucumbers.
Let’s take a job board component as an example. You estimate the amount of time to build one. There are different “what if”‘s here:
- Would it implement all of the security best practices?
- Can it scale to 100,000 job applications?
- Are there tags for skills that could be extended and grouped later, or simply a text field that means nothing in the database?
Not to mention that the plugin could be fully extensible, with tons of actions that allow for other add-ons to enhance its behavior. Or plain and simple.
There could be pagination and sorting by columns, extensible and flexible views for different jobs, API for pulling jobs remotely with JSON requests etc etc. Even if you describe these separately in the proposal, again – there are various ways to implement each one of them.
Quality is not a factor when putting estimates. It simply defines what is your forecast regarding the amount of time it would take your team to build a given project.
4. Estimates Are Expensive
When estimating a project, there are two ways to tackle it:
- Roughly put some numbers next to the main features
- Spend forever asking all the questions in the world and preparing a 30-page document with every single small details
Therefore, the common sense dictates the following:
- You probably have absolutely no idea what are the project details and there are a hundred gotchas waiting to bite you very, very soon
- You will spend a week brainstorming on something that may as well not happen at all
Since the first option is not estimating, but guesstimating, what are the options for building the most awesome proposal ever?
- Prep it for free, waste a week of your life and lose the project to a lower number
- Ask for getting paid for 40-hours of your time doing a discovery session and estimating
Things get even more complicated if you’re working with a team on a larger projects. This would require a team estimating each of the modules separately, discussing dependencies and various use cases, brainstorming together, blocking time for meetings and calls, and delaying other projects instead.
5. Separate Modules Affect Other Numbers
The main reasons I get requests for estimating a project is in order to provide a fixed fee for the final cost. While that makes sense – more or less – it’s arbitrary and an expensive process, as we already mentioned above.
The second reason however is for pricing each component separately. In other words, if a certain number is higher than the ROI for a client, they would like to drop it and focus on something else.
That’s what an average project looks like behind the scenes
Here’s the thing: most modules are not standalone. They depend on other modules, or impact the overall look and feel and functionality for a project.
For example, getting back to the job board for a second. Let’s say that we have a request for submitting CVs by employees and the client decides to drop that.
This would most likely affect several different areas:
- The look and feel – various views for displaying the CV, upload buttons, review by employees
- Uploading and editing feature for contractors
- Review options and PDF viewer for employees
- Capabilities that restrict the access to that resource
And so on.
If a client wants to substitute a component for another one, it gets even messier – I won’t even go there.
The larger the project, the more dependencies there are. The more connections and messages between different components, and the harder it is to bundle everything together and make it work smoothly.
And here’s another hidden “treasure” – when clients want to build an MVP first and they receive 80% of the functionality for a reasonable fee, the challenges come when they ask for the other 20%. Since the basic 80% often come from the WordPress core or general plugins with little to no customization, the other 20% require custom development for a live platform – which requires research and a lot of careful development and testing in order to avoid conflicts and edge cases with the existing components.
Those second 20% are often far more expensive than the initial 80% – because it’s a different type of service. The number of features doesn’t determine the amount of time and the level of skill required.
6. Estimates Prevent Innovation and Adaptivity
As we stated above, the main reason for estimates is predictability and choosing the best fit for executing a project.
But clients are often inclined to go for a cheaper solution – since it’s our psychology. In the head of a client, a request for proposal (RFP) or simply asking for a project means that each contractor will deliver the very same product.
Different contractors have different set of skills, expertise, and workflows. They operate differently and deliver different results.
Some of those are visible, others – aren’t.
And unlike the fruits in a supermarket where you can easily compare cheap tomatoes and expensive ones (they even smell differently), the only way to compare two potential custom products is to pay for both of them and use them with the same data, in the same environment – which is a nonsense.
Therefore, a lot of agencies – sometimes inexperienced, and sometimes on purpose – try to solve problems in the fastest possible way.
Bundling random plugins together that “seem to work”, but break the layout on mobile, call dozens of additional database queries and hurt the code quality of the project.
Or customizing a random ThemeForest theme so that the site looks beautiful while loading 10 different sliders with 50 scripts at the same time.
On top of that those are hardly customizable – these are general purpose solutions that solve a problem and have options, but they’re not meant to be extended infinitely – there is a certain framework in place that allows for minor changes, but that’s it. Everything extra needs to be rebuilt from scratch, and sometimes the entire project needs to be deprecated and done from ground zero.
7. Fixed Numbers Encourage Sloppy Work
At the end of the day, clients want solutions and contractors want profit.
Real data is a myth.
On fixed fee projects profit comes from spending as few hours as possible on a project, in order to prevent scope creep plus extra time and generate a good margin.
This approach discourages creativity and clean work.
It’s only logical – why double the amount of time in order to refactor the code, optimize the queries, reduce the script loads, combine and minify the scripts and styles and so forth if it’s not needed, nor budgeted, even if it’s all essential for the success of a project? And if you add that to the proposal, the final number will probably be higher than your competitors’ and you will lose the project altogether.
Estimating projects is something that should be avoided. The reason agile exists at all with variations such as Scrum, XP and Kanban, is that waterfall is an inefficient way of building software.
Projects estimated upfront suppress innovation. The team in charge isn’t motivated to invest in outstanding code quality. Different bidders try to underprice by cutting features, just as cheaper cars save on car parts that break more often.
What we do in order to prevent these is working against a budget.
When you are looking for a car or an apartment, you call your car broker or a real estate agent and tell them what you want. On top of them you give them a rough budget.
You won’t go to a Porsche or BMW dealer and tell them: “Show me all of your 200 models regardless of the fact that I have a limited budget that only 5 of your cars fit“. You need to respect both your time and the time for your technical partner.
The post 7 Reasons Why I Avoid Estimates appeared first on Mario Peshev on WordPress Development.