Many years of my experience in software (mostly web) development, including complex and often risky quoting processes I was involved in during my career at Merixstudio, has left me with the same dillemas: how to accurately quote web projects? What time buffers should I assume? What risks to consider?...
The final quote sent to the client is based on the time estimate and aforementioned factors. I'm sure the same patterns are applied by the most of worldwide web agencies which struggle with clients requesting fixed-bid assignements.
What are the client-side results of fixed-price approach?
Quotes sent in by potential contractors are probably not free of overestimating. Let's face the truth – in most of the cases it is the contractor who is more aware about the real costs and potential risks of a project.
Of course, years of experience in managing software projects allow to estimate resource needs more accurately, however even with the help of Nostradamus we are not able to predict every possible situation. And I'm positive there are more situations like this than characters in this article! Even solid track-record and extensive experience in custom web application development does not make it much easier to predict problems with various website components or with integrating the software with an external APIs.
And there comes the project specification, which would make everything clear and easy to estimate. So let's do it!
Medium- and low-budget developments created with a help of open-source solutions such as Drupal or Magento can be delivered within accurately prepared estimates and without major issues. On the other hand, custom development can create complications and getting into more and more specific requirements brings unwanted project growth. And then, we either start to try and force-fit the project in the budget or debate on whether the requirements meet preset project scope or not. Instead of working on the real project development, we waste days or even weeks talking about it, negotiating and clarifying the specification.
What if the projects were charged by only actual time spent by the agency and their developers? What if we could forget the full specification and manage the project on the go? Impossible? Well, there is a way that make it easier – the Agile approach and charging projects by man hour costs.
Agile, an alternative to the Waterfall method (which is usually charged with fixed rate) is an incremental software development method based upon assumption that project requirements evolve during the development process (it seems more natural, doesn't it?).
Working in Agile demands high discipline in project management and constant monitoring of the workflow and effectiveness. The product is being regularly presented to the client what allows to compare it to the requirements and decide if there's something to change.
Project teams are created and matched to the project by their key competencies. They are as small as possible in order to avoid any communication problems or excessive documentation – that allows to develop high-quality software quickly. Team members are free to decide how to reach particular goals, both product- and time-wise.
The software is being developed iteratively (in so called 'Sprints'), and the goal of each iteration is the delivery of a product (e.g. a particular, predetermined set of software features). Each sprint is followed by testing and compatibility verified against business requirements. Successively, features or even the whole project can be redone or pivoted.
Many books have been written on Agile, but I think the core of this method has been covered above.
Let's try and aswer the question: Why hourly rates are a better solution to charge projects than fixed pricing?
- Gathering requirements
Starting a project with creating a full specification means the crucial decisions are being made in the very beginning. Well, the question is whether we know enough about the nature of project at the moment. Changing requirements later can be difficult, not to mention how costly it can get.
Using Agile, we start working having only the business requirements and key features. The features are being adjusted after their core is created and when we have the essential information. Changes in the project are just a natural part of it in Agile approach.
- Financial risk
I suppose we can all agree that words "precise" and "long-term" assessment stay in opposite. During an estimation process we are forced to introduce project risk factors. Charging hourly rate eliminate potential risks because we cover only the real time spent to achieve particular tasks and goals.
- Common priorities
In fixed-priced projects the priorities of both sides, although common, can lead to a situation where the contractor wants to complete the project as effectively as possible in order to maximize its profit (which is dependant on spent man hours). On the other hand, the client desires a product of the best quality and the time frame is not of his concern, since it doesn’t drive any extra cost. What’s the solution to that? Decide on working with the best contractor and charge the project by the time.
- Meeting expectations
In the waterfall model, acceptances are made by stages, therefore it’s harder to track progress. Any changes made can mean throwing out parts of work already done. In the Agile model you can review the work results more often (sprints usually take weeks, rather than months), so we can track our expectations on the go.
- The project can be started earlier
In Agile approach we don’t focus on creating complex and full specification from the start. There are only particular business requirements and incremental work – from the general key features to the details. Everything is more clear, the documentation is rather simple and comprehensible as it covers only the particular iteration.
- Tracking progress and verifying requirements
In fixed-price approach the project is verified by the client after certain stage is fully complete. In fact, we don’t have a possibility to verify the requirements as they go. In Agile model we track progress constantly, we are well informed and have full transparency in terms of requirements, especially those financial.
- Changes in the project
Charging hourly rates allow us to change priorities at all times. Agile gives us full control – we can pause what we do at the time and simply change direction. Constant tracking of the outcome enables us to improve the project on the go – sometimes the best ideas come up in the middle of the work. Agile makes them real without the necessity to renegotiating, meetings, quoting and futile documentation.
- In the end, it’s... cheaper
That’s right! As I mentioned before, when charging fixed rate, the agency must calculate any risks and problems, what can lead to overcharging. Charging hourly rate is actually cost-effective, because the client pays only for the real work done.
- The time we don’t track
Discussion whether a particular piece of the spec means this or that is a waste of time. Have you ever calculate time spent on discussions and negotiating? Not to mention planning every little detail of the project before starting it.
OK – I believe I’ve done my best to convince you to charge projects hourly, using Agile methods. I’m sure that during the next initial negotiations it's very likely to hear following question:
“Agile is great, the sprints are awesome, that’s it – let’s do it! But first I need to hear how much it’s going to cost?”
There’s no way to charge by fixed price in Agile – it just doesn’t work like that. I’m aware, though, that cost must be somehow estimated (budgets, budgets, budgets), so it’s always helpful to conduct couple of workshops and specify business requirements (having a list of user stories and wireframes help a lot to determine estimates). With a help of workshops and tech-planning and project analysis it allows us to estimate the number of sprints (cycles) required to deliver the outcome by a particular team and pre-calculate the cost. We can also give a range to the client based on how many cycles a project of similar nature normally takes.
Mind that nobody can promise the estimates will match the final budget. There’s no way to predict any modifications or the elements that would need further discussions.
Full transparency and control is crucial to approach the project holistically, especially from the financial perspective.
Sound good, doesn’t it? Well, another doubts can arise - what if...
"If I pay for each man hour, how I can be sure that they won’t tweak the hour count?”
A diligent analysis of the potential contractor is crucial. A product of the highest quality that fully meet client's expectations can only be made by a team we fully trust and the team than can have proven track-record.
What to consider when choosing an agile development agency?
The size and the experience. If the agency runs for years and its portfolio shines with robust projects, delivered for trusted brands and employs top experts of particular competencies, it’s sure a way to go with. It’s always a good idea to reach out and get to know the tools the particular agency uses to track progress.
And if you're searching for coding and programming partner, here are some practical tips on web design outscourding to Poland.
So, what now? If you work with an experienced team you trust and you are part of the development process, the success is sure. Agile approach is likely to deliver much better outcome than the fixed price projects.