Tips for those planning a new project
So you have an idea for a new project, no matter what it is: developing a new service, an additional section of an ongoing project, or, for example, automating a process. Here are a few tips on what is important to do before you start development to increase the chances of accomplishing your idea with minimal loss of nerves and money.
Reduce the original scope of work to the minimum necessary
In our practice, we often encounter overloaded projects at the beginning. When you want to construct a spaceship from scratch, implement multiple additional functions, build a service that solves all the problems in the world before they arise. We always try to convince clients to simplify the first stages and reduce the amount of work, and there are many reasons for that.
The more complex the system, the more difficult and longer it is to develop. In the case where there are no working functions at the start, even the estimation of such a project will take too much time, and at the same time will be more like a wild guess. You can analyze 2–3 basic functions in detail, but each addition is like thinking dozens of steps ahead — with each new detail the accuracy decreases, and the result is distant. To cover the risks, programmers have to increase the estimates several times, but even this is not enough, because the number of details and nuances are often underestimated. And it is much harder to describe in detail a complex component system and the chance that small errors at each stage will eventually accumulate increases. The development in these cases is delayed, costs more, or becomes unprofitable both for the client and for the contractor, which causes a loss of quality, negativity, delayed deadlines.
Moreover, the main function of the system often takes up less than 20% of the resources spent and could already benefit the customer and users.
System complexity is an unavoidable problem as the project ages: increasing technical debt, increasing support costs, unpredictable problems, and unintuitive system behavior in some cases — pains of products with a history. But the complexity grows gradually, features are developed in response to real user needs based on feedback, and it all manages to make a profit, paying back the rising costs. If you can start simple, it’s much better to do so.
Besides, it’s not guaranteed that the bunch of features that you’ve thought out so carefully and spent time and money on will be needed by real users. So if you’re doing something new — if possible, start only with what you need, so that you can get feedback as quickly as possible and understand where and what you need to tweak and what is not important.
Formulate expectations
The second common problem that can ruin a project is the difficulty with the same understanding of the task by all participants in the process. Yes, we are talking about Product Requirement Specification, its existence, and other problems with it. We can talk a lot about Product Requirement Specifications and their preparation, in the following articles we will return to them, now we will highlight some simple but important points.
If we set aside formalities, the Product Requirement Specification is primarily necessary so that all parties understand the task in the same way and talk about the same thing. Initially, when there is an idea for a project, the understanding of what should be implemented is only in your head. And unfortunately, transferring this understanding is a difficult task. By Murphy’s Law, if there is the slightest chance that you can be misunderstood, you will be misunderstood. You won’t say some things, thinking that they are implied, some is sure to be misunderstood by the performer, something will be forgotten by everyone. The most common problematic cases are:
1.Lack of specificity and too vague description, without mentioning the details critical to the client. Let’s imagine the situation, the client asks for “an ordinary online store: a list of products, shopping cart, the simplest filters.” The contractor nods and does it, and eventually turns it in:
It turns out that the client imagined and expected this in his head:
As you can see, even on one page of the standard catalog the difference between the initial estimate of the contractor and what the customer expected can be huge. There is a conflict where everyone is right, the client didn’t get what he wanted, although he expected that it is implied and included in the budget, and the performer did only what was asked. And the project is rarely limited to one page. Of course, it’s not so terrible, if the customer has no problem adding fixes for extra budget, but what if the original budget was already spent. In this case, getting out of the situation without a loss will be problematic.
2. The second problem is the opposite — too formal description in the text of each function separately, without working out the connections between them and the idea of how-it-will-work-in-the-end. Often such a Product Requirement Specification is written by a client, based on the results of client inquiries and his wishes. But in the end, you end up with a multi-page document, and the client himself can’t even clearly say whether this is what he imagined or not. Often the client agrees to the Product Requirement Specification without studying it because everything is clear, but there is no desire to delve into 50+ pages of A4. The client doesn’t get a complete picture of the product, and as in the first case, it seems that everything is as it should be. At least the idea that something is wrong doesn’t immediately arise. In the end, the result is not quite what the client expected. Although such a case is much less scary than the first, it’s still painful.
To solve both of these problems and improve the initial understanding of the task performer, here is our advice. First of all, the Product Requirement Specification is needed to take the idea of the problem out of our heads in a way that is clear to all parties. And there is nothing more unambiguous than a picture. A picture is always easier and better explains the main point. A picture tells you right away if something is missing. It’s much easier to understand how components of the system are connected. Even the process of visualizing your thoughts into a tangible result will already make you think through all points and reveal non-obvious problems. It will save money and time. Of course, there will be a need for descriptions of pictures, explanations of the difficult moments, and so on. But these will be the explanations on top of a common understanding. It will be much easier to get a picture in your head than wading through tons of text formal Product Requirement Specifications.
We are talking about prototyping. Designers can help with this, but the initial visualization is better to do yourself, at least to feel your idea. It doesn’t require special tools. Enough scheme manually on paper or schematic blocks (rectangles, lines, text) using figma.com. In cases where a picture is not appropriate, as in the internal calculations of the conditions for automating the process, come up with 2–3 examples of how the system should work if you had to perform the process manually.
Contact us to discuss your project
And with a minimized task and a prototype, we will implement your project without any problems. However, other developers will be happy with a project with such input, so we recommend it anyway. What is important to do during the development to minimize problems even more and be sure that everything goes as it should — we will tell you in the following articles.
