09. September 2018
Cost estimation, fixed price and agile development
How do you estimate the effort of projects in advance and does it always make sense? What are the alternatives to the classic fixed price?
The Dilemma
As most of the other agencies we also run mainly project business. The customer usually wants a fixed price in advance for the implementation of his Internet project. Usually the customer doesn't know exactly what he needs in his project, has problems to define the requirements and processes functionally and technically clearly, which is perfectly normal if you don't deal with internet projects every day. Ideally, the customer often wants suggestions from the service provider on how to implement the project, together with a fixed price offer, usually without having to invest money in advance. Often the customer also asks several service providers to compare offers. However, many customers overlook the fact that these offers are anything but comparable without a clear definition of requirements.
Depending on the complexity, the development of a corresponding concept or even initial sketches can quickly cost the service provider hours or days and thus a lot of money. It is usually anything but certain that the service provider will be awarded the contract in the end. With two to three inquiries of this kind per week, it is not possible, especially for small and medium-sized agencies, to permanently go into free consulting and conceptional advance performance with only potential prospect of a project. Of course, there are positive exceptions to this rule, but in most cases it works as described above.
Agile fixed price
The agile fixed price is a mixture of fixed price offer and agile methods and also offers budget security. Agile projects rely on the mutual trust of developer and customer as well as close cooperation. Changes in requirements are not a problem, but the basis of an agile project. In order to define a price framework, customer and developer jointly make estimates of the project's business value, risks, effort and costs. This means that they jointly determine the overall value of the project and which components the project must have, such as news management, search function and a contact form. The service provider guarantees to deliver all these functions, but you do not define in advance to the last detail in which level of detail this should happen. In the development process, function by function is developed together with the customer and it is determined which detailed functions are required in each case. If it turns out, for example, that the customer has many special functions in the news system such as tagging, category menu, news archive, comment function, ... it can happen that the effort that went into this, makes the other functions such as search and contact form more simple to implement. In any case, the customer receives the implementation of his functions, but can still shift the weighting in the development process and prioritize exactly what he really values on the website and what less.
According to expenditure / agile
This method requires the greatest possible trust of the customer towards the service provider as well as the active cooperation of the customer in the development process and is usually only applicable after some time of cooperation. An example of the advantage of billing on a time and material basis would be, for example, the execution of a TYPO3 update of a website. Many of our customers want a precise estimate of the effort required to carry out a TYPO3 update of their system in advance. This means for us that we sometimes already need budget to calculate these costs. For example, you have to invest 3 hours to analyze a project in order to estimate the total costs of a TYPO3 update. Let's assume, for example, that we estimate the update to take 8 hours for the actual implementation. In addition we have to add a security buffer of 2h for unforeseeable problems, if the customer asks for an absolute fixed price. After that the customer will hopefully release the 10h for the implementation and the TYPO3 update will be done.
In this example the customer pays up to 13h for a TYPO3 update. If he would have renounced a fixed price and its estimation, one could have gone directly into the implementation without estimation and saved at least 3h. It is a method where the customer has no costs for any overheads through analysis, calculation, formulation of an offer, the total costs only go into the pure implementation and one reaches the goal faster. Nevertheless, it is always possible to give at least a rough estimate of the effort in advance and then work closely with the customer, present results and cost status from week to week, and together with the customer, if necessary, shift priorities, add or remove functions. If the customer is willing to take part in the development process and trust the service provider, he can be rewarded with a cheaper and faster project and maybe even better results than with rigid advance planning. We advise you to have the courage for this!
With agile project management, projects that go beyond a comparatively simple issue such as a TYPO3 CMS update can be managed in an orderly fashion, even though there is no detailed concept in advance. What agile project management is, is explained in the video at the beginning of this section.
The company sitegeist from Hamburg, Germany, goes even further and says "no waste!", they even completely renounce contracts with their customers and work only on a time and material basis, as long as the customer likes cooperation and results. No money of the customer goes into estimations, offers, contracts, negotiations, etc. what is meant by "waste" here.
More about this here: https://sitegeist.de/blog/re-a-l-blog.html
Possible solutions
Working out the requirements for a fixed price offer
The fixed price offer is (unfortunately) still the most common calculation method for internet projects. In the ideal case you have a clear basis for planning, but you have to make some effort before the project. All requirements must be specified and worked out in sufficient detail before the project. It requires abstract and theoretical imagination on the part of the customer about the structure of the later web site or web application. It is almost unavoidable that not every aspect can be considered in advance and that there will still be changes once you get into the development process. You might even specify things that later turn out to be unnecessary and wrong. The service provider usually has to register, recalculate and renegotiate later changes with the customer as a "change request". Thus, some time is quickly spent on administrative tasks - time that could also be invested in the actual development of the project. In any case, the "requirement engineering", i.e. the elaboration of the requirements in order to be able to submit a fixed-price offer, is an effort that we usually charge for.
What kind of information is needed for a fixed price offer for an average website project based on a Content Management System such as TYPO3? We try to list it here as an example without claiming completeness:
- Definitions of the requirements for the design of the web site
- Target group
- Marketing intentions
- Corporate Design (Logo, Colors, Fonts, ...)
- Picture or video material
- Links to competitors
- Links to other projects that the customer likes
- Links to other projects that the customer does not like
- ...
- Definition der Frontend Umsetzung des Designs der Web-Site
- Welche Browser Abdeckung ist gewünscht?
- Welche Mobilgeräte sollen unterstützt werden?
- Unterliegt die Frontend Umsetzung der Einhaltung von Barrierefreiheit gemäß BITV 2.0 o. ä. gesetzlichen Regelungen?
- Benötigt die Web-Site ein Druck-Layout
- Definition des Hostings der Web-Site
- Ist ein Hosting Vertrag vorhanden und wenn ja mit welchem Anbieter in welchem Tarif?
- Soll ein neues Hosting angemeldet werden?
- Wenn ja, mit welchen Anforderungen?
- Definition zu evtl. bereitsd vorhandener Web-Site
- Ist bereits eine Web-Site vorhanden, deren Inhalte übernommen werden sollen?
- Wenn eine vorhanden ist, auf welchem System basiert diese?
- Um wie viel vorhandene Inhalte handelt es sich, wenn diese übernommen werden sollen?
- Soll die vorhandene Web-Site ggf. durch ein System Update weiter betrieben und mit neuem Layout versehen werden?
- Definition der Funktionen der neuen Web-Site
- Welche Sprachen soll die neue Web-Site haben und welche Sprache soll die Standardsprache sein?
- Wie viele Redakteure mit welchen Rechten sollen Inhalte bearbeiten können?
- Welche Seitentypen soll die neue Web-Site haben? (Einspalter, Zweispalter, ...)
- Welche Inhaltselemente benötigt die neue Web-Site? (Text, Bild, Video, Bildslider, Mehrspalter, Teaser, Accordions, Tabs, Google Maps, ...)
- Wird ein News-System mit News-Artikeln benötigt?
- Welche Listen- und Detailansichten benötigt das News-System, wird bspw. Tagging der News-Artikel, Kategorisierung, Kommentarefunktionen, News-Archiv, ... benötigt und wie sollen sich diese Funktionen jeweils verhalten?
- Werden ein oder mehrere Kontaktformulare benötigt?
- Was soll genau nach dem Absenden der Kontaktformulare passieren? (Speicherung, E-Mail Versand, Empfänger-Verteilung, CRM-Anbindung, ...)
- Was für weitere Funktionen soll die Web-Site haben? (Suchfunktion, Shop, Login-Bereich, Nutzer-Registrierung, Events, ...)
- Auch hier muss jede Funktion einzeln noch im Detail spezifiziert werden.
- Definition, ob der Kunde Beratung oder Service zu folgenden Themen benötigt
- Inhaltspflege / automatisierte Inhaltsübernahme
- Projekt-Dokumentation / Redakteurs-Handbuch
- Schulung im CMS oder anderen Systemen
- Systemwartung und -updates nach Start des Projekts
- Konzeptionsworkshop
- Suchmaschinenoptimierung
- Social Media
- Marketing
- ...
If the customer alone is able to provide all this information in detail in advance, an offer can be made directly without further costs. In most cases, however, this is not the case, and we organize, for example, a joint workshop or the like to work out these requirements together.
Conclusion
It does not always have to be the classic fixed price, although we are sure that it will never completely die out, as many organizations will not be ready to leave their traditional ways and budget planning for a long time to come. Therefore, we think a hybrid model of both worlds like the agile fixed price often makes sense.
If you want to plan and / or implement your Web-SIte or Web-Shop project with us, please contact us.
Matthias Krappitz aemka 
Some of our happy clients
