How to do a project analysis?

Developing new software is not just about programming and a bunch of lines of code. Software is a product whose creation requires understanding the client, the target group, the risks, and other aspects crucial to creating a quality tool.

Knowing the client and their business

The first thing to do is to fill the gap between the client and the contractor. The client often does not understand how software development is done, just as we have no insight into their business. So several meetings with the client are needed to go through their entire business model, down to the very details.

At this stage, you need to talk to the client, as well as their employees or target audience, in short, everyone who is important for the future product. Each of them may have information that the others do not consider important or do not know.

For example, if you are developing an internal system for a car company, you will hardly find out the real problems on the production line from the CEO of the company (even if he claims that he knows them).

During these meetings, you should be prepared to be asked "why?" very often. This is the only way to get to the real essence of why the project is being done, what processes can be improved, and what problems it can solve.

What are the client's ideas about the project?

But you are not entering the process described above completely blind. You have a rough idea from the project sponsor (product owner) about their vision of the project. This is generally based on the project inquirydo and the first "feeler" meeting where they outline their ideas to you.

At this point, it is important to remember that not everything the product owner tells us is a fact. Some things may be assumptions that we should confirm or deny.

For example, when you are creating for the B2C sector, a common assumption is the target audience. A big warning sign can be when a client asks you a question: "Who is your target audience?", they reply, "Well, everyone". Of course, you may come across an experienced client who regularly pays marketing companies to define their target group and target their marketing campaigns to them. With these clients, you have a significant advantage and a piece of work done.

For the B2B sector, there tend to be "tricky part" processes in the company. What are the real problems of the employees, how the processes work in theory and in practice, etc? However, it is not the rule that managers don't know their company. There are plenty of managers and CEOs who know their company inside and out and will give you a pretty accurate description of most of the things you need to know for initial project analysis.

Is this sledgehammer big enough to crack a nut?

The next crucial point is to determine the size of the project. Sometimes a client has certain ideas about a project, they see their dream product as massive, complex, and riddled with functionality down to the last detail. Whether that idea is based on some historical fact or the notion that the target audience can't be without that particular functionality, etc., we always need to explain to them that we are building a minimum-value product (MVP) version first. We give this version to the target group for feedback and we debug the application.

In countless cases, we have seen that, in agreement with the client, we have left out some functionalities, with the understanding that we will wait to see if the target group really needs them. In a huge percentage of cases, we found that the target group did not need them at all. Instead, they asked for other functionalities that could have been done with the money saved. In fact, the worst product is one that has 100 functionalities, but 3 are actually used. This is exactly the principle of agile development - spend money only on what makes sense and what will bring some value that the user of the product asks for.

Finishing the analysis

The whole analysis process can sometimes seem quite lengthy. However, it is absolutely necessary to correctly identify risks, and establish a high-level estimate of the project cost and the assignment. The client should keep in mind that every hour spent on the analysis and assignment will save a potential day of development. After all, there is a big difference when a dead end is hit during analysis or wireframing or if it happens during development.