CRM implementation without TK: road to nowhere

Published on November 23, 2016

CRM implementation without TK: road to nowhere

    Finalizing standard software to customer requirements is a mundane matter if it is properly organized. However, it is often possible to meet examples when developers undertake to perform work without technical specifications (technical specifications) at the insistence of the customer. What happens in the end? Both sides drive themselves into a hole that they dug themselves. The developer does not suspect that he will be forced to complete the amount of work many times larger than anticipated, and sooner or later he will stop this work, having choked on the customer’s bloated appetites, which will grow exponentially without formal restrictions. In such a situation, the developer risks never completing the work, and the customer never gets the desired result. In the early stages of the company’s development, we visited this pit repeatedly,

    The first part on how to write a technical task is by reference .

    We are CRM developers. Our RegionSoft CRM is a fairly powerful professional business solution. The system is desktop and we very often get customers who need a full-fledged implementation project with sharpening for individual client features. Someone has a special sales cycle, someone needs to track the transport, the third one needs special reports, setting up a KPI system or business processes. Plus, there are still implementation features, for example, distributed offices, branches, setting up telephony, commercial equipment, etc.

    In particular, for CRM, and in general, for any corporate software, the following scheme is suitable: licenses + improvements + implementation. A client can buy licenses, install software, independently take documentation, figure it out and start working. Can buy licenses, order revision, and the system administrator will do the rest. Or he can buy licenses and order implementation. Well, a bunch of all three elements is also possible. So, the stages of refinement and implementation always require the preparation of technical specifications, which will gradually indicate all the work, dates, prices and other conditions.

    We would not sigh and did not raise the problem of working with TK again, but would cut and saw the code with the entire development team, if it were not for the stumbling block, which we meet very often - customers do not want to draw up a technical task for revision. They do not want TK, that is, they actually find the right way to never sign an act. Here are the most common reasons.

    • And so everything is clear - why waste time?
    • Everything is simple here! Yes, I'll explain on the fingers.
    • I do not know how to compose it.
    • Why should I pay for what will be included in the next release?
    • Do you make up TK for money ?!

    Let's take a look at these issues in detail, because one paragraph of the list is clearly not enough.

    TOP 6 customer phrases - the right way to piss off a developer

    And so everything is clear - why waste time?

    Developer Comment: To define clear objectives and goals by formalizing them on paper. Indeed, what is negotiated verbally cannot be used as a direct indication of action. Also, verbal agreements are subsequently easy to interpret to whom it is convenient. And if the TK is voluminous and requires a long implementation period, then who will recall which formulations the parties used when stipulating the requirements for revision?

    We have a basic solution - CRM, there are requirements for it to be finalized. It happens that we take up the development of entire modules or an additional software solution to CRM (as it turned out, for example, with GeoMonitor and RegionSoft Retail ). The client has a business that he wants to automate. He has a set of problems that this automation should solve: increase sales, streamline processes, reduce time for routine, make transactions and warehouse transparent, etc. We understand how our software works, to the client - how his business functions. And when we meet, we must understand each other.

    The mistake of many vendors is that they offer a solution and do not want to delve into the customer’s problem. The client’s mistake is to see the problem bigger than it really is and demand “redo everything”. Drawing up a technical task is the very process during which it is possible to correlate requirements and possible solutions. Moreover, most of the time, finalization of technical specifications will cost less due to the fact that programmers will not spend an infinite number of man-hours on a project.

    How to understand each other while working on TK?

    • Speak a common Russian (other) language. It is unlikely that every client will understand the phrases “backup the database to the backup server” or “roll up the update on production”. It is necessary to listen to both sides: the vendor’s story about the software’s capabilities, the client’s story about the business needs, ask questions and start compiling TOR for exactly those features that really need to be improved.

    • Make the terms of reference in stages: divide the upcoming work into blocks indicating the amount and terms for each of the groups of work.

    • Best of all, if a techie or a person who knows the process to the smallest milestone will participate in the process from the customer. With all due respect, the standard office marketer CRM will not implement.

    In general, the rule is this: to make everything clear to everyone, all features to be finalized should be spoken orally and formalized on paper.

    Everything is simple here! Yes, I'll explain on the fingers

    Developer comment: It happens that a small change in one mechanism cascades pulls a whole set of related changes in other places, which needs to be analyzed and taken into account when preparing for work. It also happens that for the implementation of a seemingly simple task, significant changes are required in the engine of the mechanism, changing its architecture. Drafting of technical specifications helps to think through these points and work out the right decisions, as a result of which the work will be done better, with fewer errors and debugging, and there will be less pitfalls and “surprises” in the development process.

    It seems to the customer that changing a sales cycle, creating one report or fastening a Gantt chart is simple. Moreover, he probably google or told him that this is done in several dozen lines of code. Yes, experienced programmers can handle the code of these entities themselves, but the customer does not realize that all this needs to be built into the architecture of the main program and, for the sake of “well, there’s a little tweak,” you will have to thoroughly change the logic of a module or system.

    Therefore, it is important to carefully study the basic functionality of the program, compare it with the needs of the business and understand what is really missing. It is simple to do this: put the demo version for the main users and work in the system for several days, fixing in a separate document what your team lacks. Then, in the list, you need to prioritize, exclude the intersection of units, once again generate a document and apply this list to the vendor, who, together with the customer, will start compiling the ToR.

    I do not know how to compose it

    Developer comment: But you can, in plain language, voice the requirements for functionality that must be created. This can be done in a thesis form, and details can be specified verbally. But in the end, TK is a developer based on your requirements and taking into account all the details. After all, you do not have the right to count on the fact that you will be done work that is not specified in the ToR! You didn’t even pay for them ... Right?

    It turns out, the main thing is to convey the requirements. TK is a working document in order to understand the purpose, objectives and vision of a product. An act will be signed on it, according to it, programmers from the vendor team will conduct the development. For them, this is an instruction according to which they advance in development. TK - it’s not at all 100 pages (although it happens 400, well, it’s in large integration projects), it can be a couple of points, but they must be. The client, in turn, will be able to accept the work, checking the terms of reference - and in case of collisions show the developer what has been done wrong. Well, or vice versa.

    Why should I pay for what will be included in the next release?

    Developer Comment: No one knows in advance whether a revision ordered by you will be included in a standard solution in future releases. This is determined much later on the advice of developers when preparing global updates. However, indeed, any refinement with its usefulness for a wide range of consumers can be included in a standard solution. This is a developer's right and is not discussed.

    We have such a practice - we introduce the best solutions and improvements to the release. Whoever saw RegionSoft CRM closer, they could notice how functional and deep it is in terms of its capabilities. This is achieved precisely due to the continuous implementation of new functions, including from client requests.

    But the question is completely incorrect - firstly, not the fact that the revision will be included in the release. Secondly, you need it now, you are its investor and it will be implemented for you as soon as possible, tested on your data and implemented by you. A release with your features may happen in a year and a half, because the backlog is big - usually a couple of major releases in advance. Moreover, all tasks from the backlog are mandatory discussed within the team for relevance and the need to introduce functionality into the release. Finally, even if a cool revision falls into the new release, it will be deeply refactored, universalized, and, quite possibly, will be significantly different from your implementation.

    Yes, programmers do not understand anything in sales (business, stock, accounting, etc.)!

    Developer Comment : Whether or not programmers understand sales, it does not correlate with the need to draw up a statement of work. It is compiled so that the development department can perform specific tasks and deliver ready-made mechanisms to the customer.

    Here it’s even worth expanding the answer by points:

    • The programmer can participate in the discussion, but your technical specifications and future architecture of the development / implementation logic are drawn up by the engineer / chief developer (it can be called a team leader, product manager, product partner), who knows the business perfectly from the client side - otherwise it would be simple no one designed so many functions without understanding how they can work inside business processes.

    • The customer himself is a consultant to the vendor, and when he understands what he wants, the developer is much easier.

    • The vendor understands business, if only because he is a business in himself and works with his own products as a client. For example, we have RegionSoft CRM for all our employees in Regionsoft - we use it in all scenarios: as a sales, calling, mailing list, bug tracker, correspondence journal, integrate with 1C, set goals, plan, evaluate KPI and so on. Accordingly, there is a clear idea of ​​how the average client works. By the way, a great way to test the program.

    As a rule, a development company is always an expert in the industry for which it is developing. Without this, you can write separate scripts and modules, but by no means complex systems.

    Do you make up TK for money ?!

    Developer Comment: In order to draw up a statement of work, a certain amount of work is necessary. This can only be done by specialists with sufficiently large qualifications who know the system from the inside and understand the wishes of the customer. This is not an easy job. At times, the entire success of the project depends on a well-thought-out and high-quality TK.

    Of course, for a simple TK of two or three points, money is not taken. But for the rest you need to pay as part of the project. And there are a number of economic, functional, and even psychological reasons that are worth telling in more detail.

    • The employees who make up the ToR on the side of the developer (as a rule, these are 2 people or more) spend their working time on it, shifting other tasks. Accordingly, this is work.

    • After drawing up the TOR, the client can go to the competitor with a ready “gift” - why should we pay for this stage of the work?

    • TK is a part of the integration project, and certain functional work is carried out at the stage of its preparation.

    • What is given for free is not appreciated - the client treats the document as an optional bureaucratic formality. While it should be the main working paper.

    By the way, “investing” in TK most often leads to much greater savings than its cost: you pay only for accurate, substantiated improvements. But this does not mean that having drawn up the ToR, no comments can be made anymore. Can. Having previously made additional work in the existing terms of reference.

    I meant different!

    Developer Comment: Human thoughts are mysterious. Today I want green tea, and tomorrow I will be pulled for coffee. If there is no TK, then it is impossible to predict what the customer implied when he said, for example, that “by clicking on the green button, integration with 1C should take place”. What does this mean? Interpretations can be a lot. Maybe you need to upload payment from 1C to CRM? Or maybe unload the bills? Or do you need a report on stock balances? In TK there should be uniqueness.

    If the vendor makes concessions and agrees to work without a technical task, then he will most likely hear this objection when the time comes to sign the act of completion. And to object, sorry for the tautology, he will have nothing. As well as proving that the client must pay for remodeling everything that is presented to him. But the lack of TK makes defenseless not only for the developer, but also for the client himself.

    Usually after several iterations of what the client implied without TK, it turns out something like this

    Formulating tasks and changing them on the fly without a document at the base, the customer actually subscribes to an endless project. Due to the high uncertainty, the vendor’s team will not see the end and end to the fulfillment of all requirements and hundreds of reservations to them, which means that it will gradually begin to postpone the completion and implementation in favor of more clearly defined tasks. This is not an insult or a quarrel - it is optimization of labor and business. The client himself should be interested in the quick implementation of the project - since business automation is a competitive advantage and it is a working tool. The faster you get it, the faster you will reach a new level of labor organization, productivity and, ultimately, profitability.

    Business Intelligence and TK

    This is such a textbook and unbearably terrible story that it is worthwhile to devote a separate post unit to it. SAP introduced the fashion for business analysts. And they from SAP around the world are very powerful guys with a strong technical, financial and managerial background. Sapovtsy, especially abroad, are well aware of the price of time, timing, TK. In Russia, it sometimes seems to me that they only took over the pressure in communication, ironed suits and words like mitap, call, feedback, follow-up (communicate on occasion - business analysts are cool guys!). At my place, I met business analysts with a liberal education, with an incomplete higher education, and even without knowledge of the basics of working with a PC. These are such steroid salespeople. And so they act as advocates for the transaction and undertake to draw up TK. There are options.

    Everything is ready - take it and do it!In my practice, there are several dozen cases when people came with ready-made large TK prepared by external consultants. However, not one of them has reached the implementation. Everything is dirty in the discussion of this large TK. This ended. In this case, TK is written to you by a completely stranger who knows how CRM behaves in business in the general case (actually sterile laboratory conditions), but does not know at all how the program you choose will behave in your own business. Or he will draw up a statement of work for you so that it does not fit the program that you need, but one of those that he needs to sell for a percentage of the transaction.

    Here it is all about CRM!People come again from business analysts with ready-made TOR, which is completely inconsistent with our software, and it requires a lot of money to implement it, because you need to rewrite the complex mechanisms of the system, instead of adapting to the system and supplementing it with missing capabilities.

    Here in 2010 we wanted to buy CRM, TK was overwhelmed. The old technical task is a dead technical task. Business processes have changed, project curators are already different, IT infrastructure has been modernized, and the level of CRM systems has grown. 7 years for business and the IT sector is a significant time, as well as a year or two, so the old TK is simply not relevant.

    We took TK from our partners, they have recently implemented.Very weird approach. There are no two identical companies and the same processes within them. In addition, if there was an introduction of another CRM system (other software), then there can be no question of taking this TK into work - technologies from vendor to vendor are very different (even if the systems are written in the same programming language and visually resemble each other).

    The most appropriate option is that the client comes with a business analyst . Here, at least you can look into his eyes to evaluate his level and begin to discuss, just with the participation of one moreperson. But from experience, the business analyst is of little use - he will either lure you into that (those) program that pays him, or it will turn out to be the third superfluous and paid in the relationship between you and the vendor. The development team is professional enough to understand your requirements.

    So, to summarize the reasoning.

    • The terms of reference should be drawn up for any revision and any implementation.
    • Two aspects always work on a technical task.
    • Compose TK is beneficial to both the customer and the contractor.
    • The terms of reference should not be a formality or an element of bureaucracy.
    • TK is the main tool of a team of programmers.
    • Old, template, other people's TK will not help your project in any way.
    • Drafting TK significantly speeds up the deadlines for the completion of the entire project.

    Terms of Reference - the first and important part of an integration or implementation project. It depends on him how quickly and efficiently the team will cope with the work, and the customer will receive the desired software that works like a clock. Many adherents of work without TK appeared abroad, they advocate freedom of creativity and trust, wars revolve around the word “Requirements” (Product Requirements Document). In fact, this is a holivar for the sake of a holivar - it is impossible for both the customer and the vendor to work without technical specifications in the corporate sphere. You need to be able to negotiate. And TK fields are the best place to do this.

    All December we give discounts on RegionSoft CRM and all software of our own design. From December 1 to December 15 - 15% and cool installment and rental conditions. We do not have -70% and -90%, because we keep the economically reasonable price for licenses, and do not take it from the ceiling.

    And we ask those who did not pass to take a CRM survey, the results of which we will tell you just before the New Year - including the mechanics of the survey and our jambs. We ask you to answer questions in a simple form - there are only 10 plus 3 for those who are interested in learning more about us. Please reach the end of the survey, you simply skip unnecessary items.

    Take the survey here