Naturally, we always want to know the actual price of a specific product or service before paying for it. We compare the price with our financial opportunities and with acquisition value expectations. The financial side of the story is obvious. If you have $100,000, you can afford to spend up to $100,000.
The value expectation is a more intricate topic. It is subjective since it varies from person to person, business to business. In this article, we will explore the value proposition of the software development industry in exchange for your investment.
Money You Spend And Value You Get
Let’s say you have $100,000 in your bank account and invest $70,000. Your financial opportunity decreases. The question is, will the resulting value of the investment be more or less than the $70,000 you spent? Getting an answer to this question will take time, and usually there are two possible outcomes:
- Your expectations are met, the value is higher than the investment, and you’re delighted with the outcome;
- Your expectations are unmet, the value is less than the amount spent, and you’re unsatisfied.
Products and services are of a different nature. Before buying a specific product, you can explore or try it out. There are exhibitions, salons, test drives, your friends, and many other opportunities to test a product before buying, whether it’s headphones or the latest Mercedes. There are plenty of ways you can form more or less realistic expectations.
Everything is much more complicated with services, especially software development services. The reason is that every software product is unique since you either build something nobody has ever built before or use a different set of tools than your market competitors.
There are multiple reasons why the budget for creating a software product may be exceeded. The Internet is full of articles describing them. Let’s focus on the less obvious but the most widespread one.
From Software Business Idea to First Estimates
Suppose the idea of a software product pops up in your head. You start thinking and polishing it, and the idea acquires new details. There are too many details to keep in mind at some point, and you decide to write them down in a document. That’s how the scope of your product appears. In general, you understand why one may need your product, what problem this product solves, and how it can attract customers and gain overall success.
Now, it’s time for the implementation, which requires financial investment. The question is, how much money do you exactly need? To answer this question, you contact different software vendors, show them your scope, and ask for an estimate. Then, you choose the most appropriate vendor and step into the discovery phase. After that, the vendor composes a software specification, draws the screens of your future app, and tells you the final product development cost.
Read Also The Challenges of Project Estimation: Exploring the Variations
Lucky for you, the overall cost is within your expectations and financial possibilities. You’re happy! You have a budget for implementing your idea, and after some time, you’ll become a possessor of a top-notch software product that will pay off all your investments. You sign a fixed-price contract to avoid exceeding the budget, and work is carried out according to the Waterfall model.
But wait, what’s that? It seems there’s a problem ahead!
Balancing Between The Features You Want And The Features You Need
The app’s functionality, as described in scope, and its appearance, as shown on the screens drawn by the vendor, only reflect your expectations. They represent your vision of how you can solve a specific problem and how convenient it will be for people to use the final product. However, things that work in real life can significantly differ from this set of ideas.
Read Also Does Your Project Need Scope of Services (SoS) and Is It Different From Other Documentation?
Most probably, you have some experience in composing documents with Microsoft Office. Have you ever considered what percentage of its features you used in practice? Or, how often do you use the complete set of features of other enterprise software your company uses?
To find out the answer to this question, Standish Group conducted research to determine the percentage of enterprise software features that people actually use. According to the results, 45% of features are never used, and 19% are rarely used. After some time they did another research, and updated results showed that only 20% of features are often used, whereas 50% are hardly ever or never used. Years pass, but the general trend remains the same – not all features of an application are valuable for its users.
Source: MODERNIZATION. Cleaning a Pathway to Success (PDF)
In other words, the vendor could skip implementing these features, and the customer could save money for their implementation without any harm. The value of the final product would remain the same since these features would remain unclaimed.
It brings us to the conclusion that approximately 50% of time and money were thrown away, even though Product Owners and Business Analysts with solid backgrounds arranged multiple brainstorms, carried out analysis, and concluded that these features were necessary.
If you apply these numbers to your product, half of development costs give zero value increase. People won’t use features you spent 50% of your budget on and if you focus on the other half of the features and spend only half of your money, you’ll get the same product value. To avoid unnecessary expenses, you should determine what exactly is included in this “golden half of features“ that provide the primary value to the product.
Focusing on What Brings the Maximum Value
As a solution, you can abandon the “traditional” Waterfall model and use the developed documentation only as an initial plan that can be changed to achieve the product’s maximum value without going beyond the project budget. We’re talking about mixing Waterfall and Agile methodologies.
Read Also Software Development Life Cycle (SDLC). Waterfall Model
From the Waterfall model, you take the main structure of the working process, namely the sequence of the following phases: Analysis, Design, Development, Testing, and Deployment. Here, a project is divided into smaller iterative steps, each performed following the Waterfall model, plus you add Review as an extra final step. It’s required for reviewing the results you reached during each iteration. Iterations and Reviews are the parts of the Agile approach. Combining these elements, you’ll get the following:
- Each iteration is developed following the Waterfall model, which allows you to have control over its budget and scope and focus on maximizing the value;
- Iterations are small, which will enable you to get user feedback by spending a small amount of money;
- User feedback allows adjusting the subsequent iterations.
As a result, you get a fully controlled development process where each iteration can be adapted to users’ needs, which maximizes the value of the delivered result.
Among the disadvantages of such an approach we can mention decreased development speed. After each iteration, there is a labor-intensive and time-consuming process to release a new version. Then, the development team must analyze user feedback and determine the content of the next iteration.
Our practice shows that, on average, the development speed can drop by 25%. It means that after spending the whole budget, you’ll get 75% of implemented features compared to the standard development model. But these will be the features that have real value for end-users. As a counterexample, when using the standard development model, according to the Standish Group statistics, you’ll get only 20% of really valuable features and 30% of infrequently used ones. In other words, choosing this hybrid model will decrease the development speed but create more value.
In Project Management, such a mixed approach is called DAD or Disciplined Agile Delivery. It works perfectly with middle-sized businesses and profitable products. At XB Software, we have adjusted this model to better suit small businesses and startups with small budgets. We call such a corrected model BSF or Budget with Flexible Scope. When developing a product, the primary focus is on the budget, within which we build scope and plan the development process together with the client. After the scope is ready, we start implementing the project following the described iterative model, adhering to the EVM (Earned Value Management) approach. After completing the iteration, we review the project, analyze implementation and cost progress (SPI and CPI), and clarify completion forecasts. As a result, there are no unexpected budget overruns.
Conclusions
In addition to understanding the differences between the cost of a product and software development services, it’s also essential to consider the impact of software development methodology on the cost and value of service. Different methods, such as Agile, Waterfall, or DAD, can affect a software development project’s timeline, quality, and overall cost. Choosing a suitable methodology for a project can lead to better outcomes and a higher return on investment. Therefore, businesses should carefully evaluate their needs and goals when selecting a software development methodology to ensure they get the best investment value. Contact us if you want to get a product with features that your users really need without exceeding the budget.