Fixed Price Software Development Projects: 3 important points to remember
There are different ways to execute a software development project. These are mainly:
- Dedicated Developer: You will get a developer who only works for you and your organization. Usually, a monthly price will be agreed upon between the service provider and the client. The developer will be working full time (approximately 160 hours per month) for the client.
- Man-and-Material/ Time-and-Material/ Agile/ Development Team: Here a project is agreed upon, but the execution will be done by a multidisciplinary team of project managers, scrum masters, business analysts, business developers, software/web developers, software testers, etc. Here oftentimes an Agile methodology is used and after each Spring (a development cycle which lasts around one month) the development times are adjusted. It is not a fixed price, but a rough budget according to which it will be developed. It could be a rough figure, but it could also be a multiple of that budget figure. In large organizations, this approach is usually preferred.
- Fixed Price: This is usually used in smaller projects, where the price AND the requirements are fixed. This article is about this type of project, and what has to be considered when executing such a fixed price project.
Introduction
A lot of small to medium-sized companies have a budget for undergoing software projects. Especially in non-IT companies, the knowledge about software projects is limited. They prefer to have a fixed price, in which the project manager within those companies can be easily communicated to the CEO or management of the company.
It would be rather tough to say: “It will take around 2 to 8 months to develop and each hour costs 100 US dollars. It could also be 14 months”.
If the IT services company tells the client, “It takes 4 months and a budget of 30’000 US Dollar”, the client’s team can make a decision upon that.
The big issue with that is -> This is not how a software project works. The following are the reasons:
- Requirements change during the project: No one knows, not even the client, what all needs to be in the software/ web solution, for it to be successful. Usually, only after a few weeks, the first version or the first web user interfaces will become visible. That is usually when the client finds out “Oops, there is this functionality, which is of utmost importance. Without this functionality, the project will not be a success”. But the project cost and the project execution has already been “fixed” from both sides, the client and the IT services company. This can be a show stopper.
- No one knows exactly how long it takes to develop a functionality: Even though a software developer can give an approximate figure on how long it takes to develop a functionality. He or she does not know it exactly. This is true for even the most experienced developer. Therefore: The larger the project, the higher the risk, that the estimate is wrong. Still, with a bigger buffer in the project estimate, the software development company somehow tries to mitigate this risk.
This means, that the IT service provider is already having the risk of not knowing whether the estimate by the developer was correct, and on top of that, the client might ask for changes within the project.
This is also the reason why, according to the much-cited Chaos Report, a large percentage (around 40 to 60 percent) of all IT projects fail.
Because in a Fixed Price Project, no one wants to give in. The client does not want to pay one US Dollar more “Because a Fixed Price was agreed upon”, and the IT Service Provider will insist on building only what was agreed upon “Because the Requirements were fixed at the beginning of the project”.
Here some points to remember to make Fixed Price Projects work
1) The requirements are fixed (and only after finishing these requirements, new functionalities are added)
Software development does not need to stop, once the initially agreed upon functionalities have been developed. Once the initial project is finished, the next step can be discussed and executed.
Tip 1: The client needs to do the following: Resist the urge to put new requirements into the running project. Even though you have the strong feeling that the project will not be worthwhile for your clients.
It will be tough enough, to make the initial requirements work. Do not add to that.
2) Availability of the client during the development period
In a fixed price project, the IT services company will allocate (in smaller projects) one to three developers, a team lead, a project manager and designer.
Once the project starts, things will go fast and time should not be wasted.
Especially important: If the IT team has questions about a task or needs feedback, it should be made available by the client as soon as possible. The worst thing which could happen is if the development team needs to wait for 2 days for client feedback and sits idle for that time.
If the development team sits idle, then that time usually deducted from the Fixed Time Budget and the team tries to finish the tasks in the remaining time. Which is usually not a good idea, but maybe the only way forward.
Therefore, to benefit from the development team and their time, the client needs to be readily available for questions from the IT service provider.
Tip 2: The best solution for this would be: The client provides a dedicated Point of Contact, which is available during development hours, during the whole development period. For example, John Smith from the client will be available from 01. July to 30. August. In this time John Smith will be available via Skype or Slack Chat and can answer the questions by the development team.
3) Provide Content in Time
In some cases, the client is required to provide texts, videos, pictures and other types of content or material.
This pre-agreed content should be provided on time.
In some cases, the development company has the possibility of using dummy texts or dummy content for the time being.
But for proper output, the content is needed in some cases.
Tip 3: Make sure to have the content (like texts or pictures) ready, when the development team asks for it.
Note: It could also be related to giving approval, to go ahead with some task, or with some project document which needs to be signed off.
4) Avoid: “But this was part of the requirement” Arguments (Additional Important Tip)
In reality, the requirements can never be fully understood or written down at the start of the project.
The software development team usually works with some sample URLs which are sent by the clients, one or two online meetings and some written material like Emails or PDFs.
There is usually a general understanding of the main functionalities, but not the 100 percent clear picture.
This can be used by both, the development company to say “But this was not part of the requirement, this costs additional” or the client to say “But this was part of the initial requirement, we definitely want this free of additional charge”.
Tip 4: There needs to be general fairness on both sides. The value for money should be there. But on the other side, it should not be that unachievable of a task, so that the development company has no profit at all from the projects.
Note: In general the client (in case he is not an IT expert) should rely on the development procedure suggested by the IT company.
Conclusion
The better way to go about software projects is with the dedicated developer or dedicated developer/ Agile approach. But this is not feasible for some companies due to budget constraints.
Therefore a lot of IT services companies provide the option for fixed-priced projects.
For the client, it is important to note that when the price is fixed, then the requirements are also fixed. Oftentimes Fixed Price is mistaken with an “All-You-Can-Eat-Buffet”, where you pay once and can eat (develop) as much as you want. On the contrary, it is more like an “A-La-Carte” menu option, where you order the steak for 5 US dollars, if you want fries with that, you need to pay 2 US dollars extra.
But also: Software development and Meal preparation are different. Because when creating a steak, the input is pretty clear. In Software development, this is not always the case.
The tips in this article will help to make fixed-price projects a success.
Interesting Articles:
How to make fixed price projects work for you
Challenges in fixed price software development
Pictures: Canva
The author: Sascha Thattil works at Software-Developer-India.com which is a part of the YUHIRO Group. YUHIRO is a German-Indian enterprise which provides programmers to IT companies, agencies and IT departments.
Leave a Reply