If you are an IT-business owner and want to create or update your own website, you may be interested in the estimation of the project by technical specialists. You can sign all the work on the project to a team of programmers and deal with other business, but then there is a serious risk of ending up with a result, you didn’t expect for. In this article, Lenal specialists will tell you how to properly estimate the project and gain understanding with the technical partner.

In order to test the viability of the idea, you need to properly analyze the project, calculate its possible budget, establish desired deadlines and choose specialists for its implementation. As in the game of chess, two players are needed to implement the project – the owner of the product and the technical partner.


Product Owner’s part

First, you personally need to have a clear vision of your future project. Next, you need to deliver this knowledge to those who’ll bring it into life. A common mistake is expecting the Tech partner’s team to read your mind. Nobody will give you any estimates at this stage. So, don’t run before you walk. Businesswise it means you should create a team from different departments within your company. Each department will have to supply you with business requirements. We especially need them in E-commerce field when an offline retailer wants to progress online. You need to take into account a lot of details: process synchronization, product specificity, digitized product range, integration with ERP and CRM systems, payment method, delivery, and more.

Description of the product

It’s great if you have any technical specifications. If no, just describe it and tell what problems you expect it to solve for your clients. At this stage, you should have answers to the following questions:

  • What is the purpose of the project?
  • Who is your audience?
  • Is there any expertise or documentation for the future project?
  • What’s the planned load level?
  • How will this product be used?
  • Who will manage the development?
  • Deadlines and budgets

Customer journey of your client

Understanding the target audience and its specificity will help the technical partner to create a project for the end user, so before starting to work on the project, you need to work out your target user in detail:

  • description of the ideal client (habits, motives, problems);
  • definition of channels of communication with the client;
  • main points of interaction with you (details of site navigation, filling out an application form, finding a contact page, etc.)
  • customer behavior model, decision-making process, and factors affecting it;

The format of business requirements doesn’t really matter. It can be a presentation or just an email.

 For example, if you have a parking service you must know that the main pain of your users is frustration when they don’t know whether there are free parking spots. You can solve it by offering them an application showing any available spaces in advance and moreover offering to pay for them by card.

What is your point of interaction with them? They enter the application, choose the parking spot and pay for it. What problems do you help to solve? You spare your customers’ nerves and save their time. That’s what you must know before you start your project: why you’re doing it, what problems do you solve and what it must look like to realize all that.

Monetization model of your project

Now we know what the customer is doing, why and how to help him. Next step is to define your monetization model of the project. What you can earn and how. Sometimes, especially in E-commerce, it can be demonstrated avoiding complex tables. You can just explain that attraction costs and sales made online are 3 times cheaper than offline so margin will grow from 30% up to 45% and that will be enough to understand how it works

This stage is also very important for imagining what kind of UX you’ll have in future. As this UX is a powerful tool of your influence upon your users. For instance, if a business owner is interested in purchases of $100,00 and more there must be deployed all user’s experience to make your customer fill his cart up to $100,00 and achieve it by offering free delivery or some giveaway or bonus. 

Enlisting specifications and limitations of the project

  • integration specifications, which means that Product Owner describes what must be integrated with what.
  • delivery terms limitations;
  • budget limitations (approximate amount planned for investment in the project);

Version release planning

Project versatility is a widespread phenomenon abroad. The first version of the project is launched as soon as possible in order to test its hypotheses and check user feedback and then refine the product.

Ukrainian customers prefer to "polish" the product until it looks flawless before demonstrating it to the world. However, it would be wiser to start work shortly so that they can immediately receive feedback through user interaction.

The technical partner usually requires information on how big the product is, what features it will have and how product owner is planning to implement future versions of the product.

Prioritizing your requirements

Both your team and the Tech partner’s team must know which things go first. It will help you to concentrate on most important tasks keeping an eye on less urgent ones and optimally distribute the load for the entire project time.


Tech partner’s part

After the owner gives all the necessary information to a Tech partner, his/her role in this process is over and all he/she has to do is to wait for the result.

Now move on to a technical partner. Having provided all information from his side, what can Product Owner expect?

Detailed analysis of project features

A professional Tech partner will do his best to get to know your project as if it was his own. You can see it if he requires all the above information from you. If he just asks for a list of features to stuff your project with, run.

You can also test it by organizing an online or offline meeting with a Tech partner and ask him to describe your product or project to you. Thus you will have an idea whether your views coincide.

Realization scheme

After you’ve set yourselves on the same page it’s time for the Tech partner to demonstrate what steps he’s going to take to realize your project - clear actions that will lead to a successful project. It is possible to organize work differently, but most often IT-companies divide work on sprints (certain periods of time) and make a list of functions to which they will work during this period.

Taking into account all delivery terms, budget and integration specifications, he can decide whether he’s going to use in-house resources or apply to some outsource teams.

Specified architecture of the project

Taking into account all project features - delivery terms, budget and integration specifics, the technical partner needs to develop the infrastructure and take into account all project databases, on the basis of which the architecture of the project and its component system (micro-services, etc.) will be built.

Detailed work breakdown structure

Experienced Tech partner can make one step forward and offer you to break down the work under your project into modules. Each module will have a fixed price. It will give you the freedom of operating your project and costs according to your budget. Besides, it can help you assess the risks and ways of solving possible issues. It’s not a free service and usually it’s a step towards more profound analysis of price for your project.

In our company we offer wire-framing, that is a schematic conceptualization of all skins, log-ins and their interaction in the application, which is schematic UX. Thus in our case, we offer well-thought use-case together with a description of all your use-cases, for example, MVP according to the project.

Why would you need it? You will have all documentation which can be realized by any team in case the Contractor lets you down.

What about Agile?

Of course, there is flexibility. But any business has certain limitations both in the budget and in the deadlines. Any project requires analysis, and if you choose a flexible way, then there is no place for preliminary estimation. If you choose an iterative method, you just need to know the rate per hour of the technical partner's team (time & material).

But if you decide to make a really good product, prepare for a tough play. Leave no space for misunderstanding. The more details you discuss the more precise your project will be. Fight for every nuance and remember to keep your Tech partner close. “Thought thrives in conflict”. It’s the same with projects. Only together you can assess if it really is worthwhile. And if yes, you’ll already have a good teammate by your side.

Add new comment