IT consulting companies today are natural competitors for freelancers, independent teams, traditional studios and outsourcing studios. When we started our business, we understood this well. We often find that both clients and colleagues do not always understand the difference. Referring to the fact that the result of the work of both developers and consultants is a conditional product with a predetermined set of properties. For many, it is an axiom to joke that consultants differ from others only in the number of zeros in project budgets.
Here we will try to explain why our services, as a rule, are more expensive, what are the features of the IT consulting business, and how consulting services differ qualitatively from the services of outsourcers and freelancers using the example of creating applications for sports. We will describe the stages that a project goes through in our company and tell you why these stages are needed.
The price problem and why many people need consulting
Consulting services are often more expensive than independent teams, freelancers, studios, and even large outsourcing companies. Any company with more than 10 people, as a rule, has an office, accounting, taxes – and the prices of consultants are higher than those of independent teams. Studios, agencies and large outsourcing companies are also burdened with such costs, but do not sell niche expertise, since they constantly work with different segments and dive into them solely within the requirements of individual projects.
How do you work with studios and independent teams?
(under the spoiler) There are probably studios and teams that act differently, but the most common practice, judging by the reviews and experience of our clients, is as we described below.
Coming to low-profile studios, the customer is faced with a lot of problems: he must develop technical specifications himself, bring a suitable design or analyze references in order to explain to the studio designer what he wants in terms of UI and visual components. In such situations, the customer also determines business requirements himself, and this is another piece of analytical work. Such work is usually carried out superficially; studios expect the client to have already formed business requirements in order to develop system ones based on them.
At the same time, customers, including those in our sports segment, do not always have sufficient resources and time. At this point, the chicken and egg dilemma arises. As a result, incomprehensible technical specifications, forgotten business requirements that begin to arise regularly already during the development process (which means they slow down the process), lack of niche knowledge that is needed in order to understand requirements that are obvious to the customer, but not obvious to the team. The IT component of a sports club is, as a rule, 6-7 websites and a bunch of IT systems for their maintenance, which are usually managed by only 1 manager. Often, he simply does not have time to prepare requirements and know the technical details of integration with the ticket system or other services.
What are we doing?
Consultants strive to close all these issues and minimize the customer’s “hemorrhoids” on these occasions. And this is what justifies their cost. In this sense, the consulting bureau saves a lot of time, since in most cases it has a good understanding of business problems, design features that can be advantageously applied, pain points of the target audience and optimal ways to solve existing problems. We ourselves prepare system and business analysis artifacts, form technical specifications, develop the design and then create the application. To stay “on topic” and maintain the relevance of our expertise, we try to maintain the prevalence of sports projects in our portfolio.
When it comes to a sports client, we already know how to integrate the systems the team works with into a single and convenient infrastructure. Usually we are talking about several sites and applications. Problems with the team’s existing products are also typical:
- Firstly, there are many sites. Main and junior squads, ticket website, merch store, etc.
- Secondly, there is a whole zoo of systems with low or zero integration (a store on Bitrix, a “ticket” on Yandex or infotech, and a CRM, some Megaplan. There are also situations when mobile applications work separately from websites or have synchronization errors.
- Third. Problems with maintaining regular news and updating other content. But here it’s out of the blue, and it’s unclear where to start writing technical specifications.
A rare IT manager is able to prepare a full-fledged technical specification and business analysis artifacts on all these issues. Therefore, usually tasks for changing, creating and integrating sports applications prepared by customers do not go beyond the dry GOST standards, are overly abstract and rarely go beyond primitive templates, and sometimes are completely absent.
Niche expertise
Even deeper consulting is implied when niche expertise is required. Of course, a good studio will be able to write code for a sports club’s mobile application no worse than a consulting bureau can do it. It will also be able to offer best practices in development, but they are unlikely to do analytical work there.
When a hockey club comes to consultants with niche expertise for an application, the club representative will first of all be asked what league the club is from, and not what framework they want to use to make the application. The fact is that the requirements directly depend on the audience. There are clubs with history, such as CSKA and Dynamo, and there are young teams. The audience is fundamentally different and everything depends on it, from design and functions to a specific technical solution, architecture, requirements for reliability and fault tolerance.
The first goal is to win the Gagarin Cup. They don’t want to create news feeds; it’s just important for them to publicize their activities. For the latter, the popularity of a sports brand is one of the main goals of the application. Still others work on image, for example, academies and children’s schools, most of which sell or plan to sell franchises.
And these goals also impact both the functionality and features of the UI. Regular studios do not understand these differences and cannot, for example, tell the customer whether the club needs a calendar of off-site meetings in the application, whether it needs loyalty program functions, etc. Often, studios work according to the templates of the most famous sports applications, simply blindly copying their functionality or borrowing their design. Consultants act differently – they study the market in search of new approaches, not only in sports, but also in applications from the field of FMCG and serving B2C clients. They borrow best practices, adapting them for sports.
Niche expertise helps prevent unnecessary expenses for the client, but the client sometimes doesn’t look so far ahead. One day, representatives of an educational institution approached us and asked us to evaluate a website project that had a lot of frills, such as a custom CMS. Knowing the needs of such clients, we recommended refusing cooperation and making a website on a banal WordPress. Thus, the client saved 70% of the budget, obtaining an identical result.
Features of our work
We always work according to SCRUM. This applies not only to the development methodology, but also to the organization of other stages, from analysis to the release of the finished product. We use two-week sprints. Within the framework of a sprint, standard meetings are used: sprint planning, daily scrum, sprint review, sprint retro.
Analysis
A client comes to us, describes what he wants to develop during an initial in-depth interview, we conduct a preliminary assessment and show an estimate. As a rule, they ask us: “Why is it so expensive?”, and we begin to explain for a long time: we offer a plan-solution, show who we worked with, explain why expertise is needed and how the results differ from what products we produced. The client understands what he is paying for, and we continue, or say goodbye, if he is not ready to accept our arguments in defense of the price, this also happens.
The first sprint allows you to dig deeper into what exactly the client wants. Sometimes it happens that the customer simply showed the application and said: “I want it just like…”, and cites the Juventus website as an example. Naturally, this does not provide information about the requirements, and they are clarified in the first sprint. We draw up briefs and conduct additional interviews, find out what exactly he liked about the reference, to what extent the functions of the reference correspond to his understanding of the product, etc. We structure the conversation in such a way as to identify the maximum needs and explain the value or uselessness of certain requirements in a specific case.
Often such interviews do not concern technical issues and are devoted not so much to sports as to business. For example, in home series there are matches that sell well, and there are low-margin events. Then we brainstorm, we have a Miro board (Diagram Flow) with questions that relate to the technical part and client touch points, then the IT architecture is described there using Data Flow and a list of main epics is compiled.