back to blog
Responsibility between the Client and the Development Company
For an outsourced software development company, communication and workflow organization are the keys to a successful and effective collaboration. If some processes remain a secret or there is a misunderstanding, the project immediately gets in big trouble. And, vice versa, if all processes are transparent and the client and the team are on the same track, the project will end in a successful realization.
In addition to communication and organization, there is also an issue of shared responsibility and trust. How do you share the responsibility for the result and whom to blame if anything goes wrong?
As a company with a proven record of projects and multiple long-term relationships with the clients, we decided to share our vision and thoughts on responsibility and communication. Hope we will inspire you to optimize your own processes too!
The basic principles of our work
We base our work on the principles that our employees live by. They are:
- Responsibility - that’s not a punishment (like a fee) or a self-punishment (negative emotions, for example). Responsibility means actions, something that will be happening at some point in time.
- Collaboration means setting adequate expectations. If a person does not say something or prefers to keep quiet, that’s not collaboration.
- Trust is the backbone of everything we do. The lack of trust results in too much energy spent on something else rather than on the actual task. But we stand for completing the tasks. No trust means there is no reason to work together.
- Any work has to be paid for. Both sides are free to choose whether they want to continue collaboration or no.
These principles are closely related to work ethics and we believe this is the right approach. Once you treat the client with respect and do not see your work as a “money opportunity” only, you will be amazed at how well you can work together.
Sharing the responsibility for the project between the team and the client
We are deeply convinced that any deviation in sharing the responsibility for the project will eventually lead to problems. SO we came up with a set of certain rules that help us avoid this issue:
We don’t work by a fixed price model, but prefer to monitor the budget. Here is how it works:
- In the beginning, we outline the project goal and the expected results. As well we negotiate the Full Flow.
- Plan and perform either a 1-week or 2-week sprints. We insist that the client is present at our weekly demos or reads our Visual Changelogs.
- As soon as we come up with the 50%, 75%, 90% and 100% of the budget, we re-estimate the rest of the work (or backlog) and, together with the client, prioritize the tasks for the rest of the budget.
- Such an approach allows us to meet both the project requirements and the budget but, at the same time, we can always implement certain changes or eliminate certain project parts.
- We request a client to have a specialist who can reply to our queries within 1 day and can independently make decisions about the project.
- Guarantees. What kind of guarantees can we give? We can guarantee that our engineers will dedicate a stated number of hours to the project. But we cannot guarantee that the final product will 100% match your expectations (though we’d love to).
- It’s highly recommended that the client also has certain responsibilities related to the product. It can be a product exhibition, a meeting with top executives, the release date -- anything that can serve as a deadline and help understand the goal of the project.
For the client, it is important to understand that there can never be a 100% guarantee of a work result. If a company is ready to give you such a guarantee, chances are high that they are scammers. An experienced and professional company always considers the possibility of an error, from a human factor error to some malfunction in the technology.
However, proper estimation, regular sprints and reports help minimize the possibility of an error and prevent most of the possible risks.
What does Full Flow mean and why it matters?
Full Flow implies the whole process of using the app by the user, from beginning to the end, reaching the final goal. It can be extremely easy - like registering and sending a query - or complex. For example, an HR app can include a few user roles and a variety of corresponding processes: a recruiter registers a company and creates a job opening, a candidate responds to the opening, a recruiter sees the response and reacts.
We emphasize the Full Flow negotiation as it helps us better understand the requirements and serves as a canvas for app development. With Full Flow, we always have a plan to stick with and the whole team understands the goals.
What about Visual Changelog?
This is a document of a presentation and it contains a detailed description of the changes that we implemented in a week. Visual Changelog is our own innovation that we came up with in order for the client to better understand the workflow and all the processes.
With the help of Visual Changelog, the client is always aware of everything that happens on a project. Such transparency gives the client better control over the project and guarantees we are on the same path.
Responsibility of a client
As a development company, we are ready to deliver a high-quality result and amend the product to the client’s expectations.
However, software development is not a lopsided game. In order for the development team to fully understand the client’s needs and create the corresponding product, it is important that the client does some work as well. It includes:
- Outlining the business goals
- Defining the KPIs
- Having a list of desired skills needed from a team
- Having a description of a product and a draft list of its functionality
- Research on the target audience
A client does not just approach a development company with a big idea. For successful mutual work, both sides have to work hard and fully understand the consequences in order for the project to be realized. Otherwise, the team may forever struggle with the ever-changing requirements without coming close to the goal.