Analysis of assignment and pricing of software project development

It is common for an inquiring potential customer to send me a document and expect me to make a price estimate based on it. I have seen, in companies, that some salesman will probably roll the dice and tell the inquirer some amount to make the potential customer happy. However, I only do qualified estimates and for those you need to have enough background and think about other things... Nowhere have I found a clearly described procedure for doing a good analysis and not pricing a project. So, I will share information on how I do analysis and price estimation in this article.

First, we need to be clear about what we are talking about. It addresses how to competently estimate a software project that is being custom developed. Not selling a finished thing/software like selling caterpillars/phones/license keys.

Pricing

Valuations for buildings, for example, are very good. Assuming, of course, that the market does not change and therefore the price of materials and labour. For example, if you order a central heating system, you can very accurately after inspecting and measuring the house to determine the amount of material (this is the analysis of the material needed) and an experienced person, based on previous experience in the implementation of a similar project, will estimate the price, which is primarily based on the price lists of materials and the time required. Such an estimate takes some risk and profit and adds it and as a result makes a quotation to the enquirer.

Custom development

However, in the case of custom software development, every project is different if it were the same or even similar, you can use an off-the-shelf solution or a pre-built base. A typical example is eshops. You take a pre-made solution, modify the settings, change the look and feel and reprogram it. minor functions.
Or you can rent an eshop as a service, where you have the same features as others. However, nothing can be customized.

Nowadays, customized is the optimal way to manage project development: Agile development, where cost estimates may not even need to be addressed or are indicative.
However, in case of a fix-price request, you have to give some estimate. Estimates, whether of price, time or complexity, can be useful in agile development. Typically, if you are developing a large project on which the future operation of the company depends or an indicative estimate for implementing some major critical functionality in the application.

Steps of an educated guess

Someone is probably making cost estimates from a crystal ball. However, a qualified price estimate can be made better, it just takes work. Just follow a few steps. At the same time, these steps ensure that the final product meets the customer's needs.

The bigger the project the more complex it will become and the greater the likelihood and magnitude of risk that something will something is misjudged, something is done wrong or even something is forgotten. And then with a bigger project it's bigger adjustments to get it done or to get it right. Therefore, with a larger project, the need to do an initial analysis fundamentally increases and it also needs to be done in more detail and with more care.

A list of steps to be taken to provide information that clearly specifies the assignment:

1. Requirements gathering and analysis
2. Drafting and documenting requirements
3. Creating the technical specification
4. Review and approval

Requirements gathering and analysis

Meet with the customer and discuss their needs. Find out what problems he wants to solve, what his goals and expectations are. At this stage, it is important to ask many questions to understand the context and reasons for creating the application.

If the project is larger and involves multiple parties, it may be appropriate to hold a group meeting, where all stakeholders can express their needs and ideas. In addition to the managers, a rank-and-file employee of the company who is personally familiar with the activity should attend, and therefore often the person who will be using the functionality of the application.

Analyze existing solutions in the company and in the market. If there is already a system in place that the new application will replace or complement, analyse its functionality and identify problems or areas for improvement.
Explore whether there are similar applications on the market, and what functionality or features might be appropriate for your project benefit your project.
You may even find that an app with the desired functionality already exists and there is no need to waste resources (spend money, spend time) on implementing a new solution from scratch, but it will be possible to take an existing solution and modify it for your specific needs. This will save significant money, reduce start-up time and reduce the risks associated with custom software development.

Analysis is a scientific method based on the decomposition of a whole into elementary parts, a method of examining more complex facts by dissolution into simpler, basic units. The aim of analysis is to identify the essential and necessary properties of the elementary parts of the whole, to know their essence and regularities. Analysis is also a method of interpretation when we separate the individual phenomena and examine them in isolation. (The opposite procedure to analysis is called synthesis. Synthesis results in the creation of new wholes.)
The result of analysis in information systems is mainly an understanding of logic. And thus obtaining the initial assumptions for the implementation of a system or the optimization of an existing system.

Find the critical points!
Critical points in a project are key moments when serious problems can arise or when it is crucial to decide how the project will develop. Identifying and managing them increases the success of the project. Map out the project timeline and identify the most important deadlines (e.g., completion of a phase, client approval).
Analyze the dependencies between tasks. Each task may be dependent on other tasks. If one task falls behind, it can affect the entire project. Use a Gantt chart or Critical Path Method (CPM), which are tools for visualizing how different activities are connected and which ones have minimal flexibility in deadlines.

Requirements Development and Documentation

Functional Requirements

Define what the application should do - that is, its functions. These may include specific operations that users can perform, e.g. "user can log in with email and password", "system automatically notifies of upcoming events" etc.
TIP: Write down the features that will not be in the app as well, so it is clear what the app will not do. Write down features you plan to add in the future, because we can then use this to guide development and prepare the app for easy addition of these features later. features.

Functional Requirements

Determine requirements for performance, security, usability, scalability, maintenance, etc. These requirements do not focus on specific features, but on how the application should work.

Prioritize Requirements

In collaboration with the customer, prioritize each requirement. This will help you determine which features must be done in the first phase and which can wait when planning development.

TIP: Create a group of requirements that are a must for the first meaningful release of the application. Pass this version of the application to the into production for use. Then add additional features incrementally.
This is the end of the tav implementation. minimal value product (MVP), which has the advantage of giving you a quick response to your application and you can acquire your first customers.

Creating a technical brief

Because the language of the user and customer is different from the language of the information system developer, it is a good idea to create glossary of terms and write down every unknown term. Typically words from the programming field or from corporate slang.

Project introduction and description

Start the document with a simple summary of what the application is intended to do and what problems it is intended to solve.

Functionality Specification

Describe each functional requirement in detail, including usage scenarios (use cases), flow diagrams, user stories, etc.

System Architecture

Design how the system will be structured. This may include database design, API interface, application modules, and how the various components will work together.

To write (plot) classes, DB structures, and usecase, ideally use the UML. This way you can create, edit and read the application development documents more efficiently.

Technology Stack

Select the technologies and tools that will be used - programming languages, frameworks, databases, servers, etc. When selecting technologies, consider their suitability for the task at hand. Often the amount of available of developers who are familiar with the technology.

Try the technologies and APIs you're using for the first time, so you know what to expect and if it's even usable. That way, you won't be stepping into the unknown and making guesses out of the unknown. This will also prepare you for the development/testing environment.

Security Requirements

Specify how security issues will be handled, including authentication, authorization, encryption, etc. If you don't specify them don't expect them to be significantly considered.

Testing

Define how the application will be tested - what types of tests will be performed (unit, integration, user), who will perform them, and what the acceptance criteria are. Who will approve from the customer that the functionality has been delivered correctly.

Development Plan

Finally, create a development timeline with milestones that will be achieved incrementally. Also include a plan to address risk and change management.

Review and approval

Provide the customer with a technical assignment for review. Go through all the key points with them and make sure they understand everything and agrees with everything. Get feedback and make adjustments if necessary. It is important that the customer fully agrees with the ToR before development begins. Once everything is agreed, have the customer formally approve the ToR. This will ensure that both parties have clearly defined expectations.

Why do an analysis and technical brief?

This systematic and structured approach will help minimize misunderstandings and ensure that application development is plan and in accordance with the customer's requirements. Both the supplier and the customer have greater confidence that everything will be as they expect.

Pay for analysis?

It is often the case that the enquirer expects the analysis and quotation to be free. And someone accepts such a request, but then receives an offer that is not supported by anything. Subsequently, after the enquirer has become a customer, the customer is surprised when he gets the result later at a higher price and sometimes they get something that doesn't match their expectations. A good analysis and a good technical specification also ensures control over the whole development process and thus contributes to the success of the project.
That is why the inquirer should pay for the analysis. Paying for the analysis has many other advantages...

Paying for an assignment analysis is beneficial to the customer for these many reasons:

• Clear definition of objectives and requirements.
• Risk and cost minimization.
• Accurate cost and time estimates.
• Quality assurance.
• Preventing misunderstandings.
• Better decision making.
• Flexibility and adaptation.
• Basis for future development.

Clear definition of objectives and requirements

Analyzing the brief helps the customer articulate exactly what they expect from the application. Often, customers have a general idea of what they want but no detailed specification. Analysis helps to flesh out that idea, ensuring that the final product actually meets their needs.

Risk and cost minimisation

Investing in a thorough analysis at the beginning of a project can save money in the long run. Without careful analysis unexpected problems may arise during development or major changes may need to be made, which can make the project costly and delay the project.

Accurate cost and time estimates

Through detailed analysis, development costs and timelines can be estimated. This helps the customer to plan budget and expect realistic project completion dates. Without this analysis, estimates are very inaccurate, leading to dissatisfaction on both sides.

Quality Assurance

A technical brief created from a thorough analysis provides the development team with clear guidelines and specifications, leading leading to a higher quality end product. When developers have accurate and detailed information, they can better focus on implementation, which reduces the number of errors and defects.

Preventing misunderstandings

Detailed analysis and subsequent technical specifications serve as a reference for the entire project. This ensures that both parties - the customer and the development team - have a clear and consistent idea of what is to be created. This reduces the risk of misunderstandings and subsequent conflicts.

Better decision making

During the analysis process, questions and ideas often arise that the customer did not initially consider. This then leads to better (timely) decision making process and optimization of application functionalities. The customer can then gain valuable insight into what features are right for them and which technological approach is most appropriate.

Flexibility and adaptation

If requirements change or new needs are discovered during the analysis, it is easier to make adjustments at this stage, than during the actual development. The analysis makes it possible to react more flexibly to changes, which is beneficial to the customer.

Basis for future development

A well-conducted analysis and technical specification serves as documentation that can be used in the future. If the customer decides to further develop or extend the application, they will have a solid foundation on which to to build on.
The technical specification can and take with this comprehensive information can request implementation with another supplier.

Delivery and commissioning of the completed project

If you are building the project on technologies you know and have tried, you have thought through the unknown technologies and API in advance, you have thought through the critical points in the project, you have eliminated the biggest risks and you have a good chance that the project will turn out well.

Agree in advance where the application will be operated and whether you expect to monitor and maintain the application afterwards. of the application.
After the project is launched, ideally perform a post-implementation analysis.
Complete and update the documentation!