The introduction of CRM without TZ: the road to nowhere
Refinement of the standard software for the requirements of the customer - this is a trivial matter, if it is properly organized. However, it is often possible to find examples when developers undertake to perform work without TZ (technical assignment) at the insistence of the customer. What happens in the end? Both sides are driving themselves into a hole that they dug themselves. The developer does not suspect that he will be forced to perform the amount of work many times more than expected, and sooner or later he will stop this work, swallowing the customer's bloated appetites, which will grow exponentially, without formal constraints. In this situation, the developer risks never complete the work, and the customer never gets the desired result. At the early stages of the company's development, we visited this pit repeatedly, so we present the second part of our TK stories - when it is not there.
The first part about how to make a technical task - by reference .
We are the developers of CRM. Our RegionSoft CRM is a fairly powerful professional solution for business. The system is desktop and we very often get customers who need a full-fledged implementation project with sharpening to the individual characteristics of customers. Someone has a special sales cycle, someone needs to track the transport, the third needs special reports, setting up a KPI system or business processes. Plus, there are still some implementation features, for example, distributed offices, branches, setting up telephony, commercial equipment, etc.
')
In particular, for CRM, and in general, the following scheme is suitable for any corporate software: licenses + rework + implementation. A client can buy licenses, install software, independently take the documentation, figure it out and start working. Can buy licenses, order refinement, and the rest will be done by the sysadmin And maybe buy a license and order the implementation. Well, a bunch of all three elements is also possible. So, the stages of refinement and implementation always require the preparation of a technical task in which all the works, terms, prices and other conditions will be indicated step by step.
We would not sigh and raise the problem of working with TZ once more, and would saw and saw the code with the entire development team, if it were not for the stumbling block that we meet very often - customers do not want to draw up a specification for revision. They do not want TK, that is, they actually find the right way to never sign the act. Here are the most common reasons.
Let's look at these issues in detail, because one paragraph of the list is clearly not enough.
We have a basic solution - CRM, there are requirements for refinement. It happens that we undertake the development of entire modules or a software solution that is complementary to CRM (as we did, 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 its 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 go into the problem of the customer. The client’s mistake is to see the problem more than it actually is and to demand “redo everything”. Drafting of technical specifications is the very process during which it is possible to correlate requirements and possible solutions. Moreover, most often the refinement of the TZ will be cheaper due to the fact that programmers will not spend an infinite number of man-hours on the project.
How to understand each other, working on the TZ?
In general, the rule is: for everyone to understand everything, all features that need to be improved must be spoken orally and formalized on paper.
It seems to the customer that it is easy to change the sales cycle, create one report or fasten a Gantt chart. Moreover, he probably googled or was told that this is done in a few dozen lines of code. Yes, the code of the listed entities can be handled by experienced programmers, 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 is a small workout” 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. Make it simple: put the main users demo version and work in the system for several days, recording in a separate document what your team lacks. Then, in the list, you need to prioritize, eliminate the intersection of divisions, once again form the document and refer to this list to the vendor, who together with the customer will start drawing up the TK.
It turns out, the main thing - to bring the requirements. TK is a working paper in order to understand the purpose, goals and vision of the product. An act will be signed on it, and programmers from the vendor’s team will work on it. For them, this is the instruction according to which they are progressing in development. TK is not necessarily 100 pages (although there are 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, referring to the technical task - and in case of collisions, show the developer what has been done wrong. Well, or vice versa.
We have this practice - the best solutions and improvements we introduce into the release. Who saw RegionSoft CRM closer, could notice, how much it is functional and deep on a set of opportunities. This is achieved precisely through the continuous introduction 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 to you. The release with your feature can happen after a year and a half, because the backlog is large - usually a couple of major releases ahead. Moreover, all tasks from backlog are necessarily discussed within the team regarding the relevance and necessity of introducing functionality into the release. Finally, even if a cool refinement falls into a new release, it will deeply refactor, undergo universalization and, quite possibly, will differ significantly from your implementation.
Here it is even worth expanding the answer point by point:
As a rule, a development company is always an expert in the industry for which it develops. Without this, you can write separate scripts and modules, but in no case complex systems.
Of course, for a simple TZ of two or three items, the 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, which are worth discussing in more detail.
By the way, “investing” in TK most often leads to much more than its cost, savings: you only pay for accurate, reasonable improvements. But this does not mean that having drawn up the TK, you can no longer make a single comment. Can. Having previously made additional work in the existing technical task.
If the vendor makes concessions and agrees to work without a technical assignment, then he will most likely hear this objection when the time comes to sign the act of completed work. And to argue, sorry for the tautology, he will have nothing. As well as to prove that the client must pay for redoing everything that is presented to him. But the absence of TK makes defenseless not only the developer, but also the client himself.
Usually, after several iterations of what the client without TK meant, it turns out something like this
By formulating tasks and changing them on the fly without a document at the bottom, the customer actually subscribes to an endless project. Due to the high uncertainty, the vendor team will not see the end and edge of fulfilling all the requirements and hundreds of reservations to them, and therefore, will gradually begin to postpone the refinement and implementation in favor of more clearly defined tasks. This is not a grievance and not a quarrel - it is the optimization of labor and business. The client himself must be interested in the rapid implementation of the project - since business automation is a competitive advantage and is a working tool. The faster you get it, the faster you will reach a new level of work organization, productivity and, ultimately, profitability.
This is such a textbook and unbearably terrible story that you should definitely devote a separate block of the post. Fashion on business analysts introduced by SAP. And they at 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, terms, TK. In Russia, it sometimes seems to me that they only took over the pressure in communication, ironed out costumes and words like mitap, call, feedback, follow-up (talk on occasion - business analysts are cool guys!). Here I met business analysts with a liberal education, with incomplete higher education and even without knowledge of the basics of working with a PC. These are such salespeople on steroids. And here they are advocates of the transaction and are taken to make TK. There are options.
Still ready - take and do it! In my practice, there are several dozen cases when people came with ready-made large TK prepared by third-party consultants. However, none of them has come to realization. Everything is dirty in discussing this big TZ. At this end. In this case, the TK is written to you by a completely outsider who knows how CRM behaves in business in general (in fact, sterile laboratory conditions), but does not know at all how your chosen program behaves in your own business. Or he will make you the TZ in such a way that not the program you need is suitable for him, but one of those that he needs to sell for a percentage of the transaction.
Here is all about CRM! People come again from business analysts with a ready TK, which is completely inconsistent with our software and requires huge amounts of money for its implementation, since it is necessary to cut through the complex mechanisms of the system, instead of adapting to the system and adding missing capabilities.
Here in 2010 we wanted to buy CRM, TK was lying around. The old technical task is a dead technical task. Business processes have changed, the project curators are different, the IT infrastructure has been modernized, the level of CRM systems has grown. 7 years for business and IT 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 recently implemented. Very strange approach. There are no two identical companies and identical processes within them. In addition, if there was the introduction of another CRM system (other software), then there can be no question of taking this TK into work - the 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 - the client comes with a business analyst . Here at least you canlook into his eyes to assess his level and begin the discussion, simply with the participation of another extra person. But from experience, there is very little use from a business analyst - he will either lure you away to that (those) program that is paying him extra, or he will be the third extra and paid in the relationship between you and the vendor. The development team is professional enough to understand your requirements.
So, to summarize the arguments.
Terms of Reference is 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. Abroad, many adherents of work without TK have appeared, they are fighting for freedom of creativity and trusting relationships, wars are unfolding around the word “Product Requirements Document”. In fact, this is holivar for the sake of holivar - it is impossible for both the customer and vendor to work without a technical task in the corporate sphere. Need to be able to negotiate. And TZ fields are the best place for this.
Throughout December, we offer discounts on RegionSoft CRM and all our proprietary software. From December 1 to 15 - 15% and steep terms of installment and rental. We do not have -70% and -90%, because we keep the economically reasonable price for the license, and do not take it from the ceiling.
And we ask those who have not passed, to take a survey on CRM, the results of which we will definitely tell about right before the New Year - including the survey mechanics and their jambs. We ask you to answer the questions in a simple form - there are only 10 plus 3 of them for those who are interested in learning more about us. Please reach the end of the survey, just skip any unnecessary items.
Take a poll here
The first part about how to make a technical task - by reference .
We are the developers of CRM. Our RegionSoft CRM is a fairly powerful professional solution for business. The system is desktop and we very often get customers who need a full-fledged implementation project with sharpening to the individual characteristics of customers. Someone has a special sales cycle, someone needs to track the transport, the third needs special reports, setting up a KPI system or business processes. Plus, there are still some implementation features, for example, distributed offices, branches, setting up telephony, commercial equipment, etc.
')
In particular, for CRM, and in general, the following scheme is suitable for any corporate software: licenses + rework + implementation. A client can buy licenses, install software, independently take the documentation, figure it out and start working. Can buy licenses, order refinement, and the rest will be done by the sysadmin And maybe buy a license and order the implementation. Well, a bunch of all three elements is also possible. So, the stages of refinement and implementation always require the preparation of a technical task in which all the works, terms, prices and other conditions will be indicated step by step.
We would not sigh and raise the problem of working with TZ once more, and would saw and saw the code with the entire development team, if it were not for the stumbling block that we meet very often - customers do not want to draw up a specification for revision. They do not want TK, that is, they actually find the right way to never sign the 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 make it.
- Why should I pay for what will be included in the next release?
- Do you make TK for money ?!
Let's look at these issues in detail, because one paragraph of the list is clearly not enough.
Top 6 customer phrases - the right way to annoy the developer
And so everything is clear - why waste time?
Developer Commentary: To define clear objectives and goals, formalizing them on paper. After all, that which is stipulated orally cannot be used as a direct guide to action. Also, verbal agreements are subsequently easy for someone to interpret as convenient. And if the TK is voluminous and requires a long implementation period, who will then remember exactly which formulations the parties used when they specified the requirements for refinement?
We have a basic solution - CRM, there are requirements for refinement. It happens that we undertake the development of entire modules or a software solution that is complementary to CRM (as we did, 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 its 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 go into the problem of the customer. The client’s mistake is to see the problem more than it actually is and to demand “redo everything”. Drafting of technical specifications is the very process during which it is possible to correlate requirements and possible solutions. Moreover, most often the refinement of the TZ will be cheaper due to the fact that programmers will not spend an infinite number of man-hours on the project.
How to understand each other, working on the TZ?
- Speak in commonly understood Russian (other) language. It is unlikely that every client will understand the phrases “back up the database to a backup server” or “roll up an update on production”. We need to listen to both sides: the vendor’s story about the software’s possibilities, the client’s story about the business’s needs, ask questions and start drawing up the TOR for the features that really need to be improved.
- To do the technical task step by step: to divide the forthcoming works into blocks indicating the amount and terms for each group of works.
- Best of all, if from the customer in the process will take part technician or a person who knows the process to the smallest milestones. With all due respect, the standard office marketer will not implement CRM.
In general, the rule is: for everyone to understand everything, all features that need to be improved must be spoken orally and formalized on paper.
Everything is simple here! Yes, I'll explain on the fingers
It seems to the customer that it is easy to change the sales cycle, create one report or fasten a Gantt chart. Moreover, he probably googled or was told that this is done in a few dozen lines of code. Yes, the code of the listed entities can be handled by experienced programmers, 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 is a small workout” 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. Make it simple: put the main users demo version and work in the system for several days, recording in a separate document what your team lacks. Then, in the list, you need to prioritize, eliminate the intersection of divisions, once again form the document and refer to this list to the vendor, who together with the customer will start drawing up the TK.
I do not know how to make it
It turns out, the main thing - to bring the requirements. TK is a working paper in order to understand the purpose, goals and vision of the product. An act will be signed on it, and programmers from the vendor’s team will work on it. For them, this is the instruction according to which they are progressing in development. TK is not necessarily 100 pages (although there are 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, referring to the technical task - 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?
We have this practice - the best solutions and improvements we introduce into the release. Who saw RegionSoft CRM closer, could notice, how much it is functional and deep on a set of opportunities. This is achieved precisely through the continuous introduction 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 to you. The release with your feature can happen after a year and a half, because the backlog is large - usually a couple of major releases ahead. Moreover, all tasks from backlog are necessarily discussed within the team regarding the relevance and necessity of introducing functionality into the release. Finally, even if a cool refinement falls into a new release, it will deeply refactor, undergo universalization and, quite possibly, will differ significantly from your implementation.
Yes, programmers do not understand anything in sales (business, warehouse, accounting, etc.)!
Here it is even worth expanding the answer point by point:
- The programmer can participate in the discussion, but makes up your TK and the future development architecture / implementation logic of the engineer / main developer (he can be called a team leader, product manager, or product manager), who knows the business perfectly from the client - otherwise no one has designed so many functions, not understanding how they can work within business processes.
- The customer himself is a vendor’s consultant, and when he understands what he wants, the developer is much easier.
- Vendor understands the business at least due to the fact that he is a business in itself and works with its own products as a client. For example, we have RegionSoft CRM in all RegionSoft employees - we use it in all scenarios: as a sales tool, telephone call, mailings, bug tracker, correspondence magazine, we integrate with 1C, set tasks, 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 develops. Without this, you can write separate scripts and modules, but in no case complex systems.
Do you make TK for money ?!
Of course, for a simple TZ of two or three items, the 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, which are worth discussing in more detail.
- Employees who make up TK on the developer’s side (as a rule, it’s 2 people or more) spend their working time on it, shifting other tasks. Accordingly - this is work.
- After drawing up the TK, the client can go to a competitor with a ready-made “gift” - why should we pay them this stage of work?
- TK is a part of the integration project, and certain functional works are 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 this should be the main working paper.
By the way, “investing” in TK most often leads to much more than its cost, savings: you only pay for accurate, reasonable improvements. But this does not mean that having drawn up the TK, you can no longer make a single comment. Can. Having previously made additional work in the existing technical task.
I meant something else!
If the vendor makes concessions and agrees to work without a technical assignment, then he will most likely hear this objection when the time comes to sign the act of completed work. And to argue, sorry for the tautology, he will have nothing. As well as to prove that the client must pay for redoing everything that is presented to him. But the absence of TK makes defenseless not only the developer, but also the client himself.
Usually, after several iterations of what the client without TK meant, it turns out something like this
By formulating tasks and changing them on the fly without a document at the bottom, the customer actually subscribes to an endless project. Due to the high uncertainty, the vendor team will not see the end and edge of fulfilling all the requirements and hundreds of reservations to them, and therefore, will gradually begin to postpone the refinement and implementation in favor of more clearly defined tasks. This is not a grievance and not a quarrel - it is the optimization of labor and business. The client himself must be interested in the rapid implementation of the project - since business automation is a competitive advantage and is a working tool. The faster you get it, the faster you will reach a new level of work organization, productivity and, ultimately, profitability.
Business Intelligence and TK
This is such a textbook and unbearably terrible story that you should definitely devote a separate block of the post. Fashion on business analysts introduced by SAP. And they at 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, terms, TK. In Russia, it sometimes seems to me that they only took over the pressure in communication, ironed out costumes and words like mitap, call, feedback, follow-up (talk on occasion - business analysts are cool guys!). Here I met business analysts with a liberal education, with incomplete higher education and even without knowledge of the basics of working with a PC. These are such salespeople on steroids. And here they are advocates of the transaction and are taken to make TK. There are options.
Still ready - take and do it! In my practice, there are several dozen cases when people came with ready-made large TK prepared by third-party consultants. However, none of them has come to realization. Everything is dirty in discussing this big TZ. At this end. In this case, the TK is written to you by a completely outsider who knows how CRM behaves in business in general (in fact, sterile laboratory conditions), but does not know at all how your chosen program behaves in your own business. Or he will make you the TZ in such a way that not the program you need is suitable for him, but one of those that he needs to sell for a percentage of the transaction.
Here is all about CRM! People come again from business analysts with a ready TK, which is completely inconsistent with our software and requires huge amounts of money for its implementation, since it is necessary to cut through the complex mechanisms of the system, instead of adapting to the system and adding missing capabilities.
Here in 2010 we wanted to buy CRM, TK was lying around. The old technical task is a dead technical task. Business processes have changed, the project curators are different, the IT infrastructure has been modernized, the level of CRM systems has grown. 7 years for business and IT 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 recently implemented. Very strange approach. There are no two identical companies and identical processes within them. In addition, if there was the introduction of another CRM system (other software), then there can be no question of taking this TK into work - the 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 - the client comes with a business analyst . Here at least you can
So, to summarize the arguments.
- Terms of Reference should be prepared for any revision and any implementation.
- There are always two sides working on a technical assignment.
- Making TK is beneficial for both the customer and the contractor.
- The terms of reference should not be a formality or an element of bureaucracy.
- TZ is the main tool of the team of programmers.
- Old, template, foreign TK will not help your project.
- Making TK significantly speeds up the delivery of the entire project.
Terms of Reference is 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. Abroad, many adherents of work without TK have appeared, they are fighting for freedom of creativity and trusting relationships, wars are unfolding around the word “Product Requirements Document”. In fact, this is holivar for the sake of holivar - it is impossible for both the customer and vendor to work without a technical task in the corporate sphere. Need to be able to negotiate. And TZ fields are the best place for this.
Throughout December, we offer discounts on RegionSoft CRM and all our proprietary software. From December 1 to 15 - 15% and steep terms of installment and rental. We do not have -70% and -90%, because we keep the economically reasonable price for the license, and do not take it from the ceiling.
And we ask those who have not passed, to take a survey on CRM, the results of which we will definitely tell about right before the New Year - including the survey mechanics and their jambs. We ask you to answer the questions in a simple form - there are only 10 plus 3 of them for those who are interested in learning more about us. Please reach the end of the survey, just skip any unnecessary items.
Take a poll here
Source: https://habr.com/ru/post/315888/
All Articles