How to Estimate Software Project?

There was a traveler with a very capacious backpack. With each visited inn his backpack became heavier. Each time he passed a crossing, he entered an inn and listened to the local folk about ‘the ways things have to be’. All of them had different ideas about the same topics. The traveler wrote down each of the views and put them on his back. Then he looked at the map and discovered that there was only one crossroad inn left. Armed with that relief, our voyager marched on but passed out a few meters before he saw the lodge’s signboard. The sign said: “Your business goal”.

If you want something done, do it yourself, as the saying goes. It’s not always true if you want to do it right. In that case, you better estimate your software project and outsource it to people that really know their craft; especially when it comes to software. With so many technologies on the scene and so many potential partners to get involved with, you owe it to yourself to choose wisely. To do that first, estimate the value of your software project.

To do that, you need a relationship with your partner. Buying and providing a product are two sides of the same coin. To gain value you need to understand how to cooperate with the software development provider.

Estimate the software project

There’s no need to travel across the map. You need to know where you’re going before you even start the journey. That’s why the scope, the time and the price of the software product development start and end with you. You don’t need to listen to town folks to know what you need. The software development process should and will be tailored to your needs. Your job is to know what the business goal is.

When you figure that out, the rest will follow. What you need to do is to present to the vendor a bunch of information about your company, the product you want to make and the business environment you’re running in on a daily basis. The most important part is the end-user and his needs.

Depending on the scope of the project, it takes us up to two weeks to come up with the pricing. To do that, we need a lot of information. Aside from the business goal, we are interested in:

• Products and services you sell and provide
• Industry-specific requirements and limitations (compliance, timetables, deadlines, etc.)
• Factors that shape the business or product context
• Needs and limitations of end-users. Armed with that knowledge we are able to deliver pleasurable, usable and functional experience. Each product we approach with empathy and care towards user experience design. We believe that user’s feeling is a part of a product’s success
• General understanding of the challenge that you are faced with
• Information about your technology stack to date and how are you dealing with it

• Internal project documentation about the idea of your project or/and sketch of conceptual wireframes. They are not necessary but nice-to-have. The more we will know about the project, the faster and easier we can help you, jumping in
• If you have an SRS document, that would be great too, if not read how to make a Software Requirements Specification document
• If you have a backlog, then we can jump even faster. We understand of course that this is a lot to ask. Having a backlog is not mandatory but with each passed position on the list, our job gets easier. Not only in terms of pricing but overall, when it comes to software product development
• Potential involvement of the third-party that can have a say in shaping the final product. A Venture Capital fund, an angel investor, etc.
• Features that are required by the Minimum Viable Product (MVP). It’s important for the startups (which we actively support and invest in) and enterprise-level companies alike. Startups often have to take into account investors and that means rapid software development. That leads to MVP development, which has to be developed swiftly and with high-quality in mind. On the other hand, established companies like to test ideas quickly and develop products proving the thesis. For them, MVP is a great test run and has to be built with quality and deadlines in mind. Markets won’t wait, big cities never sleep.

How not to end up in a ditch

When we have all of those, we like to talk to our client about two types of features in their product:

• Must-haves
• Nice-to-haves
• Can-wait-ones

We like to establish a pipeline for the project. Analyze it from different angles. Form a crew here at CSHARK, let them figure out the time they need to finalize the project.

We like to use the graphene metaphor during the estimation of a software project. It’s tough but flexible to some extent, so you can experiment. Software product development services are a lot like working with graphene. Even if you’re walking towards the ‘Your business goal’ inn, wind can blow you off the road and run into a ditch. CSHARK, among other areas, works with Fenergo for global banks and financial institutions. FinTech software development runs in our blood.

Now imagine: some banks we have worked for add 50,000 new records about clients a year. That’s almost 137 new clients a day. Maintaining that load (and that’s not even the biggest load) requires good software architecture, the interpenetration of internal systems and bases, data integrity and compliance. And that’s only the low-end example. That’s why, moving on to the new project, we like to predict things. Events that can stretch the infrastructure, threat the entire project.

Predictability is a must. You have to know your business, project requirements and talk to us with as much detail as possible. You simply must know the project and accept the limits. Not everything can be predicted. The unknowns will be managed and carefully incorporated into the roadmap for the project. Successful product development services require the minimization of the unknown. You have to work on that with a software development partner.

The important part is the quality of communication and honesty. Is there a legacy code? If so, what state is the application in? If you don’t have anything yet – what the product will mean for you, for your user, for the market? What problem will it solve? What challenges in the maintenance department will you predict? What number of users do you estimate?

Polish programmers will give you a hand with those estimations and help come up with realistic numbers but software product development is a two-way street. We offer services and feedback based on your domain knowledge and initial information.

Some level of flexibility on the way is required. Agile software development is known for working with the adjusted vision. Product vision, even some of the business needs can and sometimes do change. It’s natural, even expected. It’s not bad if you’re prepared and willing to cooperate. Look at what we’ve done so far in the process, look at already baked functionalities and decide what to change and how do you want us to proceed. It’s doable. It’s normal. It’s Agile.

Let’s talk about money

To estimate the software project, you have to contact us. Then we have to decide on a model. Options?

Fixed-price contract. Here you and the vendor agree on a set price and are satisfied with what comes next. With this approach, you will not go over your budget and visit the next town that lies in a valley way beyond “Your business goal” inn. The potential downside to this is that we can’t offer a large amount of flexibility. In this model, there is a very limited room for changes in the middle of the project, and the final costs, due to unforeseen changes, are greater than anticipated. In a fixed price, there are two sides: the client and the vendor. The client wants to achieve everything for the price he pays, adding more functionalities, solutions different than already planned. The vendor wants to make the project within the bounds of the contract. Instead of delivering business quality, both sides push the rope, hoping to win the battle. What happends is that software development vendor delivers the scope of the project, not the business goal. Fixed-price contracts have a well-known history of failure – companies want to change the scope of the project continuously and make it market relevant but the formula doesn’t allow for that. The result – half-baked products that stand halfway between the quality and result.

Time & Material model. In this model, benefits are going to the developer and the client. Both parties have full control over the process and the client pays no more and no less but only for the time that was spent on a project. Here changes can be made quickly, offering true rapid software development. It’s all about time and resources dedicated to development but you can earn more money in the long run, simply by introducing the product faster on the market.

At the end of the day, it’s all about value. Not the ones invested by you in our work but the ones you earn with our approach. We develop software products, not write the code. We estimate the software project and consult on business matters, not collect paychecks. We put ‘you’ in ‘Your business goal.’ What do you say, want to visit our inn?